
mm m 

塗麗麗 in 





직제지향 및 고전 
公 E 트웨어공학 


김일성종합대학출판사 



차 례 


머리 ■ 

제1편. 쏘프트웨어공학에 대한 개괄 
제1장. 쏘프트웨어공학의 범우 I 

1.1. 력사적인 측면 21 

1.2. 경제적인 측면 23 

1.3. 유지정비적인 측면 24 

1.4. 명 세작성 및 설 계 측면 29 

1.5. 개 발림 프로그람작성 측면 32 

1.6. 객체지향파라다임 33 

1.7. 용어 38 

요약 40 

보충 40 

문제 41 

참고문헌 43 

제2장. 쏘프트웨어개발공정 

2.1. 의뢰자，개발자，사용자 48 

2.2. 요구사항확정단계 49 

2.2.1. 요구사항확정단계 에서의 시험 50 

2.2.2. 요구사항확정단계 에서의 문서 작성 51 

2.3. 명 세작성단계 51 

2.3.1. 명세작성단계 에서의 시험 53 

2.3.2. 명세 작성단계 에서의 문서 작성 54 

2.4. 설계단계 54 

2.4.1. 설계 단계에서의 시험 55 

2.4.2. 설계 단계에서의 문서 작성 55 

2.5. 실현단계 56 

2.5.1. 실현단계의 시험 56 








2.5.2. 실현단계의 문서작성 56 

2.6. 통합단계 56 

2.6.1. 통합단계에서의 시험 56 

2.6.2. 통합단계에서의 문서작성 58 

2.7. 유지 정 비단계 58 

2.7.1. 유지정 비단계 에서의 시험 58 

2.7.2. 유지정 비단계 에서의 문서작성 59 

2.8. 폐기 59 

2.9. 쏘프트웨 어 생 산에 서 의 문제 : 본질 적 인것 과 우연적 인것 59 

2.9.1. 복잡성 61 

2.9.2. 순응성 62 

2.9.3. 가변성 63 

2.9.4. 비가시성 64 

2.9.5. 은총탄은 없는가 65 

2.10. 쏘프트웨 어개 발공정 의 개 선 66 

2.11. 능력성숙도모형 67 

2.12. 기 타 쏘프트웨 어개 발공정 개 선시 도 70 

2.13. 쏘프트웨 어개 발공정 개 선의 비 용과 리 득 71 

요약 73 

보충 73 

문제 74 

참고문헌 76 

제3장. 쏘프트웨어생명주기모형 

3.1. 구성 및 수정모형 79 

3.2. 폭포모형 80 

3.2.1. 폭포모형의 분석 83 

3.3. 신속원형작성 모형 84 

3.3.1. 폭포모형과 신속원형작성모형의 통합 86 

3.4. 증식모형 86 

3.4.1. 증식모형의 분석 88 

3.5. 최 종적프로그람작성 90 

3.6. 동기 및 안정화모형 91 

3.7. 라선모형 91 

3.7.1. 라선모형의 분석 96 

3.8. 객체지향생명주기모형 97 


2 









3.9. 생명주기모형의 비교 99 

요약 100 

보충 100 

문제 101 

참고문헌 102 

제4장. 개발림 

4.1. 개발림 의 조직 104 

4.2. 민주적림방법 106 

4.2.1. 민주적림 에 대 한 분석 107 

4.3. 고전적 책 임 프로그람작성 자림 방법 107 

4.3.1. 뉴욕타임스프로젝트 109 

4.3.2. 고전적 책 임 프로그람작성 자림방법 의 비 현실성 110 

4.4. 책 임 프로그람작성 자림 과 민주적림 의 초월 111 

4.5. 동기 및 안정화림 115 

4.6. 최종적프로그람작성림 116 

요약 117 

보충 117 

문제 118 

참고문헌 119 

제5장. 거래되고 있는 도구 

5.1. 계단식세련 120 

5.1.1. 계단식세련의 실례 120 

5.2. 비용 대 리득분석 126 

5.3. 쏘프트웨어 의 척 도 127 

5.4. 콤퓨터 지 원쏘프트웨 어 공학 ( CASE ) 129 

5.5. 콤퓨터지원쏘프트웨어공학 ( CASE ) 의 분류 130 

5.6. 콤퓨터지원쏘프트웨어공학 ( CASE ) 의 범위 132 

5.7. 쏘프트웨 어판본 136 

5.7.1. 개정판 136 

5.7.2. 변형판 137 

5.8. 구성조종 138 

5.8.1. 제품유지정 비단계 에서의 구성조종 140 

5.8.2. 기준선 141 








5.8.3. 제품개발에서의 구성조종 141 

5. 9 . 구축도구 142 

5.10. CASE 기술을 리용한 생산성제고 143 

요약 144 

보충 145 

문제 146 

참고문헌 148 

제6장. 시 험 

6.1. 품질문제 151 

6.1.1. 쏘프트웨어품질보증 152 

6.1.2. 관리독립성 152 

6.2. 비실행 에 기 초한 시 험 153 

6.2.1. 관통심사회의 153 

6.2.2. 관통심사회의의 운영 154 

6.2.3. 검토 155 

6.2.4. 검토와 관통심사회의의 비교 157 

6.2.5. 심사의 우결함 157 

6.2.6. 검 토를 위한 척도 158 

6.3. 실행에 기초한 시험 158 

6.4. 무엇이 시험되여야 하는가 159 

6.4.1. 유용성 161 

6.4.2. 믿음성 161 

6.4.3. 로바스트성 161 

6.4.4. 성능 162 

6.4.5. 정확성 163 

6.5. 시험과 정확성증명의 대비 164 

6.5.1. 정확성증명의 실례 165 

6.5.2. 정 확성증명 의 실례연구 168 

6.5.3. 정확성증명과 쏘프트웨어공학 170 

6.6. 실행에 기초한 시험은 누가 진행해야 하는가 173 

6.7. 언제 시험을 끝내는가 174 

요약 175 

보충 175 

문제 176 

참고문헌 179 


4 





제 7 장. 모듈로부터 적체에로 


7.1. 모둘이란 무엇인가 

182 

7.2. 응집도 

186 

7.2.1. 일치적인 응집도 

187 

7.2.2. 론리적인 응집도 

188 

7.2.3. 림시적인 응집도 

188 

7.2.4. 절차적인 응집도 

189 

7.2.5. 통신적인 응집도 

190 

7.2.6. 기능적인 응집도 

190 

7.2.7. 정보적인 응집도 

191 

7.2.8. 응집도의 실례 

192 

7.3. 결합도 

193 

7.3.1. 내용결합 

193 

7.3.2. 공통결합 

194 

7.3.3. 조종결합 

196 

7.3.4. 스탬프결합 

196 

7.3.5. 자료결합 

198 

7.3.6. 결합의 실례 

198 

7.3.7. 결합의 중요성 

200 

7.4. 자료의 교갑화 

201 

7.4.1. 자료교갑화와 제품개발 

203 

7.4.2. 자료교갑화와 제품의 유지정비 

204 

7.5. 추상자료형 

210 

7.6. 정보은페 

212 

7.7. 객체 

214 

7.8. 계승，다형성과 동적맺기 

218 

7.9. 객체의 응집도와 결합도 

220 

7.10. 객 체 지 향파라다임 

221 

요약 

224 

보충 

224 

문제 

225 

참고문헌 

227 


제8장. 재리용성，이식성，호상조작성 

8.1. 재리용의 개념 


229 







8.2. 재리용의 장애 231 

8.3. 재 리 용의 실 례연구 233 

8.3.1. 레이손미싸일체계관리국 233 

8.3.2. 토시 바쏘프트웨어제작소 234 

8.3.3. NASA 쏘프트웨어 235 

8.3.4. GTE 자료봉사기구 236 

8.3.5. 휼레트-패카드회사 237 

8.3.6. 유럽우주항공국 238 

8.4. 객체와 재리용 239 

8.5. 설계 및 실현단계에서의 재 리 용 239 

8.5.1. 설계의 재리용 239 

8.5.2. 응용프로그람의 틀거리 241 

8.5.3. 설계패런 242 

8.5.4. 쏘프트웨어구성방식 246 

8.6. 재 리용과 유지 정 비 247 

8.7. 이식성 248 

8.7.1. 하드웨어의 비호환성 249 

8.7.2. 조작체계의 비호환성 250 

8.7.3. 수자처 리쏘프트웨어의 비 호환성 250 

8.7.4. 콤파일러의 비호환성 252 

8.8. 왜 이식성이 필요한가 256 

8.9. 이식성실현기술 257 

8.9.1. 이식가능한 체계쏘프트웨어 258 

8.9.2. 이식가능한 응용쏘프트웨어 258 

8.9.3. 이식가능한 자료 259 

8.10. 호상조작성 260 

8.10.1. COM 261 

8.10.2. CORBA 262 

8.10.3. COM 과 CORBA 의 비 교 262 

8.11. 호상조작성에 대한 앞으로의 동향 263 

요약 263 

보충 264 

문제 266 

참고문헌 268 








제 9 장. 계획작성과 타산 

9.1. 계 획 작성 과 쏘프트웨 어개 발공정 274 

9.2. 기간과 비용의 타산 276 

9.2.1. 제품의 크기에 대한 척도 277 

9.2.2. 비용타산방법 281 

9.2.3. 중간 COCOMO 284 

9.2.4. COCOMO II 287 

9.2.5. 기간과 비용타산의 추적 288 

9.3. 쏘프트웨 어프로젝트관리계 획의 구성요소 289 

9.4. 쏘프트웨 어 프로젝트관리계 획의 틀거 리 291 

9. 5 . IEEE 쏘프트웨 어 프로젝 트관리 계 획 292 

9.6. 시 험 계 획 작성 294 

9.7. 객체지향프로젝트의 계획작성 295 

9. 8 . 숙련에 대한 요구 296 

9. 9 . 문서 작성 규격 297 

9.10. 계 획 작성 및 타산을 위 한 CASE 도구 297 

9.11. 쏘프트웨 어프로젝 트관리계 획의 시험 298 

요약 298 

보충 299 

문제 300 

참고문헌 302 

제2편. 쏘프트웨어생명주기의 단계 
제10장. 요구사항확정단계 

10.1. 요구도출 307 

10.1.1. 면담 307 

10.1.2. 대본작성 308 

10.1.3. 기타 요구도출기법 309 

10. 2 . 요구분석 310 

10.3. 신속원형작성 방법 310 

10.4. 인간적인자 312 

10.5. 명세 작성기 법으로서의 신속원형 작성 314 

10. 6 . 신속원형의 재 리 용 316 

10.7. 신속원형에서의 관리문제 318 









10. 8 . 신속원형의 실험 319 

10. 9. 요구사항도출 및 분석을 위한 기법 321 

10.10. 요구사항확정단계 에서의 시험 321 

10.11. 요구사항확정단계 를 위한 CASE 도구 322 

10.12. 요구사항확정단계 에서의 척도 323 

10.13. 객체지향요구가 존재하는가 323 

10.14. 항공음식전문회사 실례 연구: 요구사항확정 단계 324 

10.15. 항공음식전문회사실례 연구: 신속원형 작성 327 

10.16. 요구사항확정단계 의 난관 329 

요약 330 

보충 331 

문제 331 

참고문헌 333 

제11장. 명세작성단계 

11.1. 명세서 334 

11.2. 비 형 식적명세작성 335 

11.2.1. 실례 연구 : 본문처 리 336 

11.3. 구조화체 계분석 338 

11.3.1. 쏘프트웨 어 상점 338 

11.4. 기 타 준형 식적기 법 346 

11.5. 실체-관련모형화 347 

11.6. 유한상태기계 349 

11.6.1. 승강기문제: 유한상태기계 351 

11.7. 페트리 망 356 

11.7.1. 승강기문제 : 페트리망 359 

11.8. Z 362 

11.8.1. 승강기문제: Z 362 

11.8.2. Z 의 분석 365 

11. 9. 기 타 형 식적기 법 366 

11.10. 명 세작성 기법 들의 비 교 367 

11.11. 명세작성단계 에서의 시 험 369 

11.12. 명세작성단계 에서의 CASE 도구 369 

11.13. 명세작성단계 에서의 척도 370 

11.14. 항공음식전문회사실례 연구 : 구조화체계분석 371 








11.15. 항공음식 전문회 사 실례연구 : 쏘프트웨 어프로 

젝트관리계획 373 

11.16. 명세작성단계 에서의 난관 373 

요약 374 

보충 374 

문제 375 

참고문헌 378 

제12장. 객체지향분석단계 

12.1. 객체지향분석 382 

12.2. 승강기문제 : 객체지향분석 384 

12.3. 유스-케 스모형 화 ( Use-Case Modelling ) 385 

12.4. 들라스모형화 387 

12.4.1. 명사추출 388 

12.4.2. CRC 카드 390 

12.5. 동적모형화 392 

12.6. 객체지향분석단계 에서의 시험 394 

12.7. 객체지 향분석단계를 위한 CASE 도구 399 

12.8. 항공음식전문회사 실례연구 : 객체지향분석 399 

12.9. 객체지향분석단계 에서의 난관 406 

요약 407 

보충 407 

문제 408 

참고문헌 409 

제13장. 설계단계 

13. 1 . 설계와 추상화 411 

13.2. 작용지향설계 412 

13. 3 . 자료흐름분석 412 

13.3.1. 자료흐름분석실례 414 

13.3.2. 확장 418 

13. 4 . 트랜잭 션분석 419 

13. 5 . 자료지 향설계 421 

13. 6 . 객체지향설계 421 

13. 7 . 승강기 문제 : 객 체 지 향설 계 422 








13. 8 . 상세 설계 를 위 한 형 식 적 기 법 431 

13. 9 . 실시간설계기법 431 

13.10. 설계 단계에서의 시 험 433 

13.11. 설 계 단계 를 위한 CASE 도구 434 

13.12. 설계 단계 를 위한 척도 434 

13.13. 항공음식전문회 사 실례연구: 객체지 향설계 436 

13.14. 설계 단계에서의 난관 444 

요약 444 

보충 445 

문제 445 

참고문헌 447 

제14장. 실현단계 

14.1. 프로그람작성언어 의 선택 449 

14.2. 4세 대언어 452 

14.3. 훌륭한 프로그람작성실천 455 

14.4. 코드작성표준 461 

14.5. 모둘의 재리용 462 

14.6. 모둘시험실례선택 462 

14.6.1. 명세서시험과 코드시험 462 

14.6.2. 명세서시험의 실현가능성 463 

14.6.3. 코드시험의 실현가능성 464 

14.7. 검은통모둘시험 기법 466 

14.7.1. 등가성시험과 한계값분석 466 

14.7.2. 기능시험 468 

14.8. 유리통모둘시험 기법 469 

14.8.1. 구조적시험: 명령문피복，분기피복，경로피복 469 

14.8.2. 복잡도 A 척도 471 

14. 9. 코드관통심사회 의와 검 토 473 

14.10. 모둘시험 기법들의 비 교 473 

14.11. 무진실 474 

14.12. 객체시험에서 제기될수 있는 문제 475 

14.13. 모둘시험의 관리측면 478 

14.14. 모둘을 오유수정하지 않고 재작성하는 경 우 479 

14.15. 실현단계에서의 CASE 도구 480 


10 










14.16. 항공음식 전문회 사 실 례 연구 : 검 은통시 험 실 례 480 

14.17. 실현단계에서의 난관 482 

요약 483 

보충 483 

문제 484 

참고문헌 487 

제15장. 실현 및 통합단계 

15. 1 . 실현 및 통합에 대한 소개 490 

15.1.1. 내리실현 및 통합 491 

15.1.2. 올리실현 및 통합 493 

15.1.3. 쎈드위치식실현 및 통합 493 

15.1.4. 객체지향제품의 실현 및 통합 495 

15.1.5. 실현 및 통합단계에서의 관리문제 496 

15. 2. 실현 및 통합단계에서의 시험 496 

15.3. 도형사용자대면부의 통합시험 497 

15. 4 . 제 품시 험 497 

15.5. 인수시험 499 

15. 6. 실현 및 통합단계에서의 CASE 도구 500 

15. 7. 완전한 쏘프트웨어공정에서의 CASE 도구 500 

15. 8 . 통합화된 개 발환경 500 

15. 9. 업 무응용을 위한 개 발환경 502 

15.10. 공용도구의 하부구조 502 

15.11. 개발환경에서 제기될수 있는 문제 503 

15.12. 실현 및 통합단계에서의 척도 503 

15.13. 항공음식전문회사 실례연구: 실현 및 통합단계 504 

15.14. 실현 및 통합단계에서의 난관 504 

요약 504 

보충 505 

문제 505 

참고문헌 507 

제16장. 유지정비단계 

16.1. 유지정비의 필요성 508 

16.2. 유지 정 비프로그람작성 자들의 요구 509 


11 








부록 7 
부록 8 
부록 9 
부록 10 
부록 11 
부록 12 


브로드랜즈지역 아동병원 528 

쏘프트웨어 공학자원 533 

항공음식전문회사 실례 연구 : C 신속원형 535 

항공음식전문회사 실례 연구 : JAVA 신속원형 535 

항공음식전문회사 실례 연구 : 구조화체계분석 535 

항공음식전문회사 실례연구: 쏘프트웨어프로 
젝트관리계획 541 

항공음식전문회사 실례 연구 : 객체지 향분석 545 

항공음식전문회사 실례연구 : C ++ 실현들 위한 설계 545 

항공음식전문회사 실례연구 : JAVA 실현들 위한 설계 569 

항공음식전문회사 실례 연구 : 검은통시험실례 589 

항공음식전문회사 실례 연구 : C ++ 원천 쿄드 592 

항공음식전문회사 실례 연구 : JAVA 원천 쿄드 592 


참고문헌 593 

색인 


16.3. 유지 정 비 의 실 례연구 512 

16.4. 유지정비의 관리 513 

16.4.1. 오유보고서 513 

16.4.2. 제품에 대한 변경허가 514 

16.4.3. 유지 정 비가능성 의 담보 515 

16.4.4. 반복유지정비문제 516 

16. 5 . 객 체 지 향쏘프트웨 어 의 유지 정 비 517 

16. 6. 유지 정비 기능 대 개발기능 520 

16. 7 . 역 공학 520 

16.8. 유지정 비 단계 에서의 시험 521 

16. 9 . 유지 정 비 단계 에 서 의 CASE 도구 522 

16.10. 유지정 비단계 에서의 척도 522 

16.11. 항공음식 전문회 사 실례 연구 : 유지 정 비 단계 523 

16.12. 유지정 비단계 에서의 난관 523 

요약 524 

보충 524 

문제 525 

참고문헌 526 


로 r 로「로「로「로「로 r 

부 부 부 부 부 부 


12 


618 








머 리 ■ 


이 책의 4판은 두개의 판본으로 출판되 였다. 즉 한 판본에서는 C++, 다른 판본에는 
Java 로 코드실례 를 제 시하였 다. 그러 나 쏘프트웨 어 공학은 본질적 으로 언어 에 의존하지 않 
으므로 이 책 에서는 상대 적 으로 코드실례률 적게 제시하였다. 이 번 출판에서는 언어 에 
의존하는 상세한 내 용들은 피 함으로써 제 시된 코드실례 들이 C++ 와 Java 사용자들에게 모 
두 명 백하도록 하기 위 하여 노력하였 다. 실례 로 C++ 에서는 출력명 령 으로 cout 를， Java 에 
서는 출력명령으로 system.out.printin 을 리용하지만 여기서는 대신에 의사명령 print 를 리 
용하였 다(새 로운 실례연구가 하나의 례 외 로 되 는데 여 기서 는 완전한 실현세부를 C++ 와 
Java 로 제 시한다.). 그러 므로 5판은 4판의 두 판본을 통합한것 으로 볼수 있 다. 

5판의 기본목적은 교육을 주는데 있다. 이 책에는 매장의 중요한 부분이나 측면들을 
강조하기 위한 자료들이 추가되 였다. 실례 로 객체지향분석 이 나 객체지향설계 와 같은 중 
요한 기 법들을 개괄하고 있는《진행과정》란들을 들수 있다. 

이밖에 새로운 개요나 줄거리들이 학생들과 교원들에게 도움을 주게 된다. 또한 쏘 
프트웨어공학의 다양한 기 법 들을 수행하는 방법 들에 대 한 보충적 인 자료들을 주기 위하 
여 이 번 출판에 서 는 4판에 서보다 실 례연구를 더 자세 히 서 술하고 있 다. 

4판에 는 《 개 발림 과 거 래 도구》라는 제 목으로 된 장이 있 다. 이 번 출판에 서 는 교육 
학적견지로부터 자료들을 갱신하고 두 부분으로 나누어 그 기초를 이루고 있는 매개의 
문제 들을 보다 명백 히 강조하고 있다. 특히 4장에서는 개발림 에 대 하여 서술하고 있다면 
5장에 서 는 쏘프트웨 어 공학자들이 리용하게 되 는 도구들에 대 하여 서 술하고 있 다. 

이 전과 마찬가지 로 객 체지 향파라다임 이 고전적 인(구조화된)파라다임 보다 우월 함에 도 
불구하고 여기서는 고전적인 문제와 객체지향적인 자료들을 모두 포함시켜 주었다. 최신 
쏘프트웨 어공학교과서들에서 는 객체지향파라다임만을 서 술하고 고전적 인 파라다임 에 대 
하여서 는 기껏해서 력 사적 인 고찰만을 서 술해 주었 다. 

그러 나 이 책 에서는 경우가 다르다. 객체지향파라다임 에 대 한 요구가 높아 지 고 
고전적 인 파라다임 에 비한 그것의 우월성 이 명 백하게 증명 되 였음에 도 불구하고 고전적 
인 파라다임 에 대 한 자료들을 포함시키 는것 은 본질 적 인 문제 이 다. 그 리유는 세 가지 
측면에서 설명할수 있다. 첫째 로 고전적 인 방법 과 그리 고 그것 이 객체지향방법 과 어 떻 
게 차이나는가를 완전히 리해하지 않고서는 객체지향기술이 고전적 인 기술보다 우월하 
다는것 을 인식할수 없기때 문이 다. 둘째 로 그 리유는 기 술이 전이 일 반적 으로 서서 히 진 
행되기때문이다. 아직도 대다수의 쏘프트웨어개발기업체들에서는 객체지향파라다임을 
받아 들이지 못하고 있 다. 그러 므로 이 책 을 리용하게 되 는 많은 대 학생 들은 고전적 인 
쏘프트웨 어공학수법 들을 리용하고 있는 개 발기 업 체 들에 서 도 일할수 있게 된 다. 더우기 
어떤 개 발기 업체 가 새 로운 쏘프트웨어를 개 발하는데서 객체지향방법을 리용한다고 하 
더 라도 현존 쏘프트웨어는 여전히 유지정비되여 야 하는데 이 러한 유산쏘프트웨어는 객 
체지 향적 이 아니 다. 그러므로 고전적 인 방법을 빼버리면 이 책을 읽게 되는 많은 대 학 
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생들의 우려를 자아낼수 있다. 

두 파라다임을 포함하게 된 리유는 셋째로 객체지향기술로 넘어 가려고 하는 개발기 
업체에서 일하게 되는 대학생은 개발기업체에 새 파라다임의 우점과 약점에 대하여 조언 
을 줄수 있게 되기때문이다. 그러므로 이전 판에서와 마찬가지로 여기서는 고전적인 방법 
과 객체지 향적방법 을 비 교대조하고 분석하여 야 한다. 4판은 통합모형 화언어 (UML) 를 리 용 
하는 최초의 쏘프트웨어공학교과서인데 UML 에 대하여서는 그 책이 출판되기전에 이미 간 
단히 소개 되 였다. 지난 3년동안에 UML 은 형 식적 으로 표준화되 고 광범 하게 리 용되 여 UML 
을 리용하지 않고 객체지향분석과 설계를 서술하고 있는 모든 교과서들은 인차 낡은것으 
로 되여 버렸다. 그러므로 도식을 리용하여 객체들과 그것들의 호상관계를 서술하는데서는 
물론이고 객체지향분석과 객체지향설계를 진행하는데서 UML 을 계속 리용하게 된다. 

4판에서 소개된 또 하나의 화제는 설계패런이였다. UML 과 마찬가지로 설계패런들은 
현재 쏘프트웨어공학에서 주류를 이루고 있는 하나의 부분이다. 그렇기때문에 설계패턴 
과 관련한 자료는 의연히 중요하게 강조되고 있다. 

이 책 에서 또 한가지 새 로운 화제 는 최 종적 프로그람작성 (ex/rewe programming ', XP) 이 
다. XP 에는 론의할 문제가 많지만 학생들이 재에 대한 견해를 명백히 하도록 하는것이 
중요하다. 그리하여 이 책 에서 는 그들스스로가 XP 가 쏘프트웨 어공학에서 돌파하여 야 할 
실제 적 인 전공대 상이 라는것 을 인식하도록 하고 있다. 

이 전판에서는 문서 작성 과 유지정 비관리，재 리용과 이 식성, 시험 과 콤퓨터지원쏘프트 
웨어공학 (CASE) 도구의 중요성이 강조되였다. 이 판에서도 이러한 모든 개념들이 다같이 
강조되였다. 만약 그것들이 쏘프트웨어공학의 기초로 되는 중요한 문제 라는것을 옳게 인 
식하지 못하면 학생 들을 최 신기 술로 교육하는데 도움을 주지 못할것 이 다. 

4판에서 와 같이 객체지향생명주기모형, 객체지향분석, 객체지향설계，파라다임 에 대 
한 관리 자측의 영 향，객체지향쏘 프트웨 어의 시험과 유지정 비 문제들에 깊은 주의를 돌려 
야 한다. 객체지향파라다임에도 역시 척도들이 포함되게 된다. 이밖에 객체에 대한 여러 
가지 보다 간단한 참고내용 즉 한 단락 또는 한 문장으로 된 참고내용들을 제시하고 있 
다. 그 리유는 바로 객 체지향파라다임 은 각이한 단계 들이 수행 되 는 방법 과 관련될뿐아니 
라 우리들이 쏘프트웨어공학에 대하여 생각하고 있는 방법들과 관련되여 있기때문이다. 
이 책 에서 객체기술이 폭 넓게 서술되 고 있다. 

쏘프트웨어개발공정은 여전히 이 책의 전반에 걸쳐 기초적인 개념으로 되고 있다. 
공정 을 조종하기 위 하여서 는 프로젝 트에 대 하여 무엇 이 진행 되 고 있는가를 측정할수 있 
어야 한다. 따라서 여전히 척도문제가 강조되여야 한다. 공정개선에 주목하여 능력성숙 
도모형 (CMM) 과 CSO/IEEE 15504(SPECE) 에 대한 자료들이 갱신되였고 ISO/IEEE 12207에 
대 한 자료가 추가되 였다. 

4판에서와 같이 여기서는 600여개의 참고문헌을 주었다. 여기서는 새롭고 련관된 고 
전적 인 기 사나 책 들은 물론 현재 까지 진행 되 여 온 연구론문들을 선택하여 주었 다. 의 심 
할바없이 쏘프트웨어공학은 급속히 발전하는 분야의 하나이기때문에 독자들이 최근의 결 
과들과 그것들을 어느 문헌을 찾아야 하는가를 알 필요가 있다. 이와 함께 오늘날의 최 
첨 단연구가 어제날의 진리 에 기 초하고 있으며 어 제날의 착상이 오늘날에 와서 도 마찬가 
지 로 적 용될수 있 다면 이 전의 참고문헌들을 배제할 리유는 없다고 본다. 여 기서 는 독자 
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들이 Pascal , C , C ++, Ada , Basic , COBOL , FORTRAN 또는 Java 와 같은 고급언어들에 익 
숙하고 있으며 자료구조에 대 한 과정안을 거쳤다는것 을 전제 로 하고 있다. 

5 판의 구성방법 

5판은 4판에 서 와 같이 전통적 인 한 학기분 과정안과 보다 새 로운 두 학기 분 과정안 
용으로 출판되 였 다. 전통적 인 한 학기분 과정안에 서 는 교원 이 학생 들에 게 리 론적 인 자 
료들을 속성교육하여 그들이 될수록 빨리 과정안상 목표에 도달하는데 필요한 지식과 
기 능을 가지 도록 하였 었 다. 속성 교육을 하는것 은 학생 들이 학기마감까지 과정안상 목표 
를 완성할수 있도록 그것에 인차 착수할수 있게 하기 위 해서 이 다. 한 학기 즉 프로젝트 
에 기 초한 쏘프트웨 어공학과정 안의 요구를 충족시 키 기 위하여 이 책 의 2편에 서 는 단계 
별로 쏘프트웨어제품들의 생명주기를 고찰하며 1편에서는 2편을 리해하는데 필요한 리 
론적 인 문제 들을 서 술하였 다. 실례 로 1편은 독자들에 게 콤퓨터 지원쏘프트웨 어 공학 
( CASE ), 척도, 시험 에 대 하여 소개한다. 2편의 매장들에서는 매 단계를 위한 CASE 도구, 
척도, 시험에 대한 절들을 포함하고 있다. 교원이 해당 학기에서 2편을 인차 시작할수 
있도록 1편을 간단히 취급하고 있다. 더우기 1편의 마지막 두 장 (8 장과 9장)은 뒤로 미 
루어 2편과 동시 에 강의할수도 있다. 그러 면 학생 들은 될 수록 빨리 과정 안상 목표개 척 
을 시작할수 있게 된다. 

이 제 두 학기분 쏘프트웨 어 공학과정 안에 대 하여 보기 로 하자. 점 점 더 많은 콤퓨터 
과학 및 콤퓨터공학학부들이 졸업생들의 절대다수가 콤퓨터기사로서의 직업을 찾고 있다 
는 사실을 깨닫고 있다. 따라서 많은 단과대학들과 종합대학들에서는 두 학기분 쏘프트 
웨 어공학련속강의를 계속하고 있다. 첫번째 과정안은 대체로 리론적 인 내용을 취급하고 
있다(그러 나 거 의 언제 나 어 떤 종류의 하나의 작은 프로젝 트로 된다.). 두번째 과정안은 
주요개발림 에 의한 과정안상 목표 즉 일 반적 으로 가장 고급한 프로젝 트로 이 루어 진다. 
과정 안상 목표가 두번째 과정 안으로 될 때 교원은 2편의 강의 시 작을 서 두를 필요가 없게 
된다. 그러므로 5판을 리용하여 한 학기련속강의를 하는 교원은 제1장부터 계7장까지의 
대부분의 내용을 강의하고 그다음에 2편(제10장부터 제16장까지)강의를 진행하게 된다. 
그다음 제8장과 제9장은 학생 들이 과정 안상 목표개 척 을 진행하는동안 제2편과 병 렬로 또 
는 과정안의 마감에 강의할수 있다. 두 학기 련속강의를 할 때 에는 이 책의 장순서대로 
진행하면 된 다. 그러 면 학생 를은 다음학기 에 서 진행하게 되 는 개발림 에 의한 과정안상 목 
표개 척 을 완성할수 있 다. 

2편의 주요 쏘프트웨 어공학기 법들을 옳게 리해시키 기 위하여 매 기 법 들이 두번씩 서 
술되 고 있다. 처 음에 는 기 법 들을 소개할 때 마다 승강기 문제 를 통하여 설명해 준다. 승강 
기문제는 독자들이 완전한 문제에 적용되는 기법들을 고찰할수 있도록 하는데 적당한 문 
제로 되며 해당한 기법의 우점과 약점을 모두 강조하는데 충분하다. 그다음 새로운 실례 
연구와 관련한 부분들을 매장의 마감에 주었다. 이러한 세부적인 해결방안들은 매 기법 
에 대 한 두번째 례증을 주는것 으로 된 다. 
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문제설정 


이전판에서와 마찬가지로 네가지 류형의 문제들이 존재한다. 

첫째로 매장의 마감부분에 중점들을 강조한 문제들을 주었다. 이 문제내에는 매개 
문제를 풀기 위 한 기술정보들이 포함되 여 있다. 

둘째 로 쏘프트웨 어과정 안상 목표가 있다. 그것은 일반전화를 사용하여 서 로 의논을 

진행할수 없는 세명의 학생으로 이루어 진 개발림이 해결할수 있도록 설계되였다. 과정 

안상 목표는 16개의 개별적인 구성요소들로 이루어 져 있는데 매개 구성요소들은 련관된 
장들과 결합되 여 있다. 실례 로 13장의 주제는 설계 이 다. 그래서 이 장에서 는 과정 안상 목 
표를 쏘프트웨 어 설계 와 관련된것 들로 구성하여 주었 다. 큰 프로젝 트는 보다 작은 부분들 
로 조개 여 학생 들 이 더 잘 리해 하고 해 결 해 나갈수 있 도록 하였 다. 과정안상 목표의 구조 

는 교원이 16개의 구성 요소들을 자기 가 선택한 임의의 다른 프로젝트들에 자유롭게 적 용 

할수 있도록 되여 있다. 

셋째 로 이 책 은 상급반학생 들은 물론 졸업한 학생 들이 리용할수 있도록 씌 여 졌기때 
문에 쏘프트웨 어공학문헌에 있는 연구론문들에 기 초하고 있 다. 매 장에 서 는 중요한 론문 
들을 선택하여 주었고 객체지향쏘프트웨 어공학과 관련한 론문들도 주었다. 학생들은 론 
문을 읽으면서 물어도 보고 그 내용과 관련된 질문들에 대답도 하게 된다. 물론 교원은 
기타 다른 연구론문들을 마음대로 배당해 줄수 있다. 즉 매장의 마감부분에 있는《보 
충》에서는 련관된 론문들에 대하여 폭 넓고 다양하게 소개하고 있다. 

네번째 류형 의 문제 는 실례연구와 관련한것 들이 다. 이 류형 의 문제 들은 제 품을 처 
음부터 개 발하는것 보다 현존제 품을 수정하는 방법 을 교육하면 학생 들이 더잘 배 울수 
있 다는 관점 으로부터 3판에 서 처 음으로 도입되 였 다. 쏘프트웨 어산업 에 종사하는 많은 
중간급쏘프트웨 어공학자들이 이 견해 에 공감을 표시 하고 있다. 따라서 실례연구를 서 
술한 매 장들에는 학생 들이 갈은 방법 으로 실례연구를 수정하는데 필요되 는 적 어도 세 
가지 문제 들을 포함하고 있다. 실례 로 어 떤 장에 서 는 학생 들이 그 실례연구에 서 리용 
한것과는 다른 설계기법을 리용하여 실례연구를 재설계할것을 제기하고 있다. 또 다른 
장에서는 학생들이 다른 순서 로 객체지향분석단계를 수행하게 되면 어떤 결과가 발생 
하게 되는가 하는것을 제기하고 있다. 실례연구에 있는 원천코드를 보다 쉽게 수정하 
기 위 하여서는 World Wide Web 상에서 홈페지 www.mhhe.com/engcs/ compsci/schach 를 
리용할수 있 다. 

web 싸이트는 또한 완전한 PowerPoint 강의록은 물론 이 책에 있는 모든 그림들에 대 
하여 명백히 정통할수 있게 한다. 

교원들의 해답지도서는 파정 안상 목표에 대하여서는 물론 모든 련습에 대한 자세 
한 해 답을 주었 다. 교원들의 해 답지 도서 는 McGraw - Hill 에 서 엄 을수 있 다. 
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제 1 편 

쏘프트웨어공학에 대한 개괄 

이 책에서 제1편에 포함된 9개의 장들은 이중적인 역할을 놀고 있다. 이 장들에서 
는 독자들에 게 쏘프트웨 어개 발공정 에 대 하여 소개하며 이 책의 개 괄에 대 하여 서술하 
고 있다. 쏘프트웨 어개 발공정 은 쏘프트웨어 를 개 발하는 과정 이 다. 제 품은 착상으로 시 
작하여 마지막에 폐기로 끝난다. 이 과정 에 제품은 요구사항확정과 명세작성, 설계, 
실현，통합，유지정 비，최 종적 으로 페 기 등과 갈은 단계 를 통하여 개 발된다. 쏘프트웨 
어개 발공정 에 는 또한 쏘프트웨어 를 개 발하고 유지정 비하는데 리용하는 도구들과 기 법 
들이 포함된다. 

계1장《쏘프트웨어공학의 범위》는 쏘프트웨어제품을 위한 기법이 비용상 효과적이 
여 야 하며 쏘프트웨 어제 품개 발림성 원들사이 에서 건설적 인 호상작용을 촉진시켜 야 한다는 
데 대하여 지적하고 있다. 이 책 전반에서는 객체의 중요성을 강조하고 있다. 

계2장의 제목은 《 쏘프트웨 어개 발공정》이 다. 여 기서 개 발공정의 매 단계 들에 대 하 
여 상세 히 론의한다. 이 장에서는 쏘프트웨 어공학의 많은 문제들이 론의되지 만 그 해결 
방안에 대 하여 서 는 제 시하지 않는다. 대 신에 독자들에 게 매 문제 들이 이 책 의 어 느 부분 
에서 고찰되는가를 알려 준다. 이 장은 이 책의 나머지부분들에 대한 안내서로 된다. 이 
장은 쏘프트웨 어개 발공정 의 개 선에 관한 문제 들의 고찰로 결속된다. 

제 3장 《 쏘 프트웨 어 생 명 주기 모형》에 서 는 여 러 가지 서 로 다른 쏘 프트웨 어 생 명 주 
기모형들을 상세히 론의하고 있다. 여기서는 폭포모형，신속원형작성모형, 증식모형, 
최 종적프로그람작성，동기 및 안정 화모형，라선모형 들을 서 술한다. 독자들이 특정한 
프로젝 트에 대 하여 적 당한 생 명 주기모형 을 결 정할수 있 도륵 여 러 가지 생 명 주기모형 
들을 비교하였다. 

제 4장의 제 목은《 개발림》이 다. 오늘날 프로젝 트는 규모가 아주 커 서 주어 진 시 
간내 에 개 별적 으로 완성할수 없다. 그리하여 쏘프트웨어 를 전문으로 하는 개발림들에 
서 는 프로젝 트연구에 서 서 로 협 력하여 실 현 하고 있 다. 이 장에 서 론의하게 되 는 중요 
한 론점은 개발림성원들이 제품개 발에 함께 참가하도록 개발림을 어떻게 조직하겠는가 
하는것 이 다. 개발림 을 조직하는 방법 들로서 는 민주적 인 개발림 과 책 임프로그람작성 자 
개발림，동기 및 안정 화개발림 그리 고 최 종적 인 프로그람작성 림 들을 포함한 여 러 가지 
방법 들이 있다. 

제5장에서는《거 래도구》를 론의 하고 있다. 쏘프트웨 어공학자들은 리 론적 으로나 실 
천적 으로 여 러 가지 많은 도구들을 리용할수 있 어 야 한다. 이 장에 서 는 여 러 가지 다양한 
쏘프트웨어공학도구들을 고찰하게 된다. 이러한 도구들중의 하나는 큰 문제를 보다 작은 
문제 로，보다 다루기 쉬 운 문제 로 분해하여 실 현하는 기 술인 계 단식세 련 이다. 또 다른 도 
구는 비용 대 리득분석인데 이 기술은 쏘프트웨어프로젝트가 재정적으로 실현가능한가를 
결정하는 기술이다. 그다음 를퓨터지원쏘프트웨어공학 ( CASE ) 도구가 고찰된다. CASE 도구 
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는 쏘프트웨어공학자들로 하여금 쏘프트웨어를 개발하고 유지정비하는데 도움을 줄수 있 
는 쏘프트웨어제품이다. 

마지막으로 쏘프트웨 어개 발공정을 관리 하기 위 하여 프로젝트가 제 궤도에 있는가 하 
는것을 결정하는 여러가지 량들을 측정하는것이 필요하다. 이러한 측도(척도)는 프로젝트 
의 성공에서 결정적인 작용을 한다. 제5장의 마지막 두개의 론점인 CASE 도구와 척도에 
대하여 제10장부터 제16장까지에서 상세히 취급하는데 여기서는 쏘프트웨어생명주기의 
특정한 단계 들에 대 하여 서 술한다. 매 단계 를 적 절 하게 관리하는데 필 요한 척 도는 물론 
그 단계 를 지 지 하는 CASE 도구에 대 하여 서 도 론의 한다. 

이 책에서 한가지 중요한 론점은 시험이 제품이 의뢰자에게 배포되기전에 지어 쏘프 
트웨어생명주기의 매 단계의 마감에서 수행되게 되는 분리된 단계가 아니라는것이다. 그 
대 신 시 험 은 모든 쏘프트웨 어 생 산활동과 동시 에 진 행 되 게 된 다. 

계6장 《시험》에서는 시험의 기초를 이루고 있는 개념들이 론의된다. 쏘프트웨어 
생명 주기의 개 별적 인 단계 에 대 한 특정한 시험 기법 들을 제10장부터 제16장까지 에서 언 
급한다. 

제7장의 제목은 《모둘로부터 객체에로》이다. 여기서는 콜라스와 객체 그리 
고 객체지향파라다임이 구조화파라다임에 비하여 보다 성공적이라고 하는것과 관 
련한 상세한 설명 이 제 시 된다. 이 장의 개 념 들은 이 책 의 나머 지부분 특히 제12 
장 《 객 체 지 향분석 단계》와 객 체 지 향설 계 를 서 술하고 있 는 제 13장 《 설 계 단계》 
등에서도 리용된 다. 

계7장의 기본착상은 제8장 《재리용성，이식성，호상조작성》에로 확장된다. 중요한 
것 은 서 로 다른 여 러가지 하드웨어 상에 서 정확히 동작할수 있 으며 의 뢰기 -봉사기 와 갈은 
분산적 인 구성 방식에서도 동작할수 있는 재 리용가능한 쏘프트웨어를 작성할수 있는것 이 
다. 이 장의 첫 부분에서는 재 리용에 대 하여 서 술한다. 즉 객체지향패 턴과 기 본구성과 같 
은 재리 용전략은 물론 재 리용의 다양한 실례연구들이 포함된다. 이 식성은 두번째 문제 점 
이다. 즉 이식성에 대하여 약간 깊이 있게 서술한다. 이 장은 CORBA 와 COM 과 같은 호 
상조작성문제 들로서 결 속된 다. 

이 장에서 다시 생각해 볼 문제는 재 리용성，이식성 그리고 호상조작성을 실현하는 
데서 객체의 역할에 관한 문제이다. 

계 1 편의 마감장은 제 9장 《 계 획 작성 과 타산》이 다. 어 떤 쏘프트웨 어 프로젝 트를 
시작하기에 앞서 전체 조작을 구체적으로 계획하는것이 본질적인 문제이다. 일단 프 
로젝 트를 시 작하면 관리 자는 계 획 으로부터 의 탈선을 포착하고 필요한 정 정작업 을 수 
행하면서 개 발공정 을 조종하여 야 한다. 또한 의 뢰 자에 게 프로젝 트를 완성하는데 얼 마 
만한 시간과 품이 드는가 하는데 대한 정확한 평가를 주어야 한다. 여기서 기능점수 
와 COCOMO II 를 비 롯한 여 러 가지 타산기 법 들이 주어 진 다. 또한 쏘프트웨 어프로직 
트관리계 획 에 대 한 상세한 설명도 준다. 이 장에서 언급한 내 용들은 제11장과 제12장 
에 서 리 용된다. 고전적 인 파라다임 을 리용할 때 기 본계 획작성 과 타산활동은 제11장에 
서 설명한바와 같이 명세작성단계의 마감부분에서 진행된다. 객체지향파라다임을 리 
용하여 쏘프트웨어를 개발할 때에는 이러한 계획작성이 객체지향분석단계의 마감에 
서 진행된다(제12장). 
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제 1 장. 쏘프트웨어공학의 범위 


를퓨터가 계산해 낸 0.00 딸라의 계산서를 받은 경영자에 대한 이야기는 널리 알려 
져 있다. 경영자는《멍렁구리콤퓨터》에 대하여 친구들로부터 조소를 받고 나서 계산서 
를 버 리 였 다. 한달후에 류사한 계 산서 가 도착하였 는데 이 때 계 산서 에 는 30일 이 표시 되 여 
있 었 다. 그다음 세번째 계 산서 가 왔다. 네번째 계 산서 가 한달후에 또 왔는데 그 계 산서 와 
함께 0.00 딸라에 대 한 계산서 를 당장 물지 않으면 가능한 법적행동으로 넘 어 가겠다는것 
을 암시한 전보문이 왔다. 

120일로 표식된 5번째 계산서에는 그어떤 암시도 없었다. 즉 이러한 미치광이기계 
에 의하여 자기 기 업체의 신용이 떨어 질가봐 두려워 경 영 자는 쏘프트웨 어공학자인 친구 
를 불러 불쾌한 이 야기 를 모두 말해 주었 다. 웃지 않으려고 하면서 그 쏘프트웨 어공학자 
는 0.00 딸라에 대 한 계산서를 우편으로 보내 라고 경 영 자에 게 이 야기해 주었 다. 이것은 바 
라던 효과를 보았으며 그로부터 며 칠후에 0.00 딸라에 대한 수납이 되였다. 경 영 자는 앞으 
로 콤퓨터 가 여 전히 0.00 딸라를 빚지고 있 다고 주장할수 있는 경 우를 고려하여 그것 을 
조심스럽게 서류철에 넣어 두었다. 널리 알려 진 이 이야기의 몇가지 속편들은 잘 알려 
져 있지 않다. 며칠후에 경영자는 자기의 은행관리인에게 호출되였다. 은행관리인은 행표 
를 보여 주면서 《 당신의 행표입 니 까?》하고 물었 다. 경 영 자는 그렇 다고 하였 다.《 당신 
令 왜 0.00 딸라에 대 한 계산서를 썼는지 나에게 말해 주겠습니까?》라고 물었다. 

그래서 그 이 야기전부가 되풀이되였다. 

경 영 자가 이 야기를 끝내 자 은행 관리 인은 그에게 조용히 물었다. 

《당신은 0.00 딸라에 해당한 계산서가 우리 를퓨터체계에서 무엇을 하였는지 생각해 
보았습니까?》 

어떤 를퓨터전문가들은 이 이 야기를 듣고 옷을수 있다. 

결국 우리모두는 그 원래의 형태에서 0.00 딸라에 대한 글자들에도 지불을 독촉하는 
결과를 빚어 낸 그러한 제품을 설계 또는 실현하고 있다. 

지금까지 개발자들은 언제나 시험단계에서 이러한 오유를 범하군 하였다. 그러나 이 
것을 비웃는것도 의미가 있다. 왜냐하면 개발자들은 그 제품이 손님들에게 배포되기전에 
얼마간은 오유들을 발견하지 못할수 있다고 하는 우려를 하고 있기때문이다. 

그리 유모아적 이 라고 할수 없는 한가지 쏘프트웨어 오유는 1979년 11월 9일 에 발견되 
였다. 전략공군사령부는 전 세계적군사명령 및 조종체계 ( WWMCCS ) 콤퓨터망이 이전 쏘 
련이 미국을 겨냥한 미싸일을 발사하였다는것을 보고하자 매우 놀라게 되였다 [ Neumann , 
1980]. 사실은 바로 약 5년후에 나온 전쟁유희영화에서와 같이 모의공격을 실제적 인것으 
로 해 석하였 던것 이 다. 비 록 국방성 이 실 제자료에 시 험자료를 넣 음으로써 정 확한 기 구에 
대 한 세 부를 주지 않았다고 할지 라도 이 문제 를 쏘프트웨어 오유에 기 인 시키 는것 은 타당 
할것 같다. 전체 체계가 모의와 현실을 구별할수 있도록 설계되지 않았거나 또는 사용자 
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斗가 Therac -25 의 학적 선형 가속기 에 서 나오는 방사선의 한계 량초과의 결 과로 죽게 ᅧ 였 다. 

원 인은 조종쏘프트웨어 의 오유에 있 었 다. 

1991년 만전쟁시기 스쿠드미싸일이 패트리오트요격미싸일방어를 뚫고 사우디이 라비아 
다흐란가까이 에 떨 어 졌 다. 미 군병 사 28명 이 죽고 98명 이 부상을 당했 다. 패트리 요트미 
날 의 쏘프트웨어 는 루적시 간오유를 포함하고 있 었 다. 패 트리 오트미 싸일 은 한번 에 _ 시 간 
만 동작하고 그다음에 시계가 재설정되도록 설계되였다. 

결국 오유는 크게 나타나지 않고 발견되지도 않았다. 

만전쟁 시 기 다흐란에 서 패트러오트미싸일 전원은 lOOh 이 상 계 속 동작하였 다. 

이것은 루적된 시간불일치가 체계가 정확하게 동작할수 없을 정도로 크게 나였다. 
fl 쟁시 기 미 국은 스무드미 싸일 을 방어 하기 위하여 패트리 오트미 싸일 을 배 에 d 어 이 
다엘로 수송하였다. 8 h 만에 시간계수문제를 발견한 이스라엘은 즉시에 그에 귀하여 
주의 제 작자들에 게 통보하였 다. 제 작자들이 오유를 가능한껏 빨리 퇴 치하였국 만 비 
착 으로 스쿠드미 싸일 의 타격 을 받은 다음에 야 새 로운 쏘프트웨 어 가 도착하였 다【 4 ellor , 

，4]. 

리 가 계 산서문제 나 반항공방어 를 취 급한것 은 많은 쏘프트웨어 들이 잔류오유를 
예산을 초월하여 늦게 배포되게 되기때문이다. 쏘프트웨어공학은 이 문제를 
기 위하여 노력하였 다. 달리 말하면 쏘프트웨 어공학은 사용자들의 요구를 만 
는 오유 없는 쏘프트웨어 를 주어 진 기 간과 예산으로 생산하는것 을 목적 으로 
a 는 학문이다. 더우기 쏘프트웨어는 사용자들의 요구가 달라 질 때 보다 쉽게 
수 있 어 야 한다. 이 목적 을 달성 하기 위하여 쏘프트웨 어공학자들은 기 술적 및 
측면에서 폭넓은 기능을 소유하여야 한다. 이러한 기능은 프로그람작성뿐아 
인구사항확정으로부터 유지정비에 이르는 쏘프트웨어생산의 매 단계에 적용되 
it 다. 

프트웨어공학의 범위는 아주 넓다. 쏘프트웨어공학의 일부 측면들은 수학이나 






1.1. 력사적인 측면 

사실 발전기가 고장나기는 하지만 그것은 로임지불명단관리제품에서보다는 훨씬 적 
다. 또한 때때로 다리들이 무너지지만 조작체계의 붕괴보다는 훨씬 적다. 쏘프트웨어의 
설계와 실현，유지정비가 전통적인 공학학문들과 갈은 지반을 가지고 있다는 확신에 기 
초하여 1967년에 NATO 연구그룹이 쏘프트웨 어공학이라는 용어를 만들어 냈다. 

쏘프트웨어 의 구축이 다른 공학적 인 과제 들과 류사하다고 하는 주장은 도이월 란드의 
가르미슈 ( Garmisch ) 에서 열 린 1968 NATO 쏘프트웨어 공학대회에서 찬동을 밤았다. 이러한 
찬동은 그리 놀라운것은 아니다. 즉 대회라는 명칭이 쏘프트웨어생산이 공학적인 활동으 
로 되여야 한다는 믿음을 반영해 주고 있다. 

대회참가자들이 내린 결론은 공학적인 학문의 원리와 파라다임을 리용하여 그들이 
명명한 쏘프트웨어의 위기문제를 해결하여야 한다는것이다. 이러한 위기는 바로 쏘프트 
웨어품질이 일반적으로 접수할수 없을 정도로 낮으며 최종기한과 비용의 한계가 맞아 떨 
어 지 지 않는다는것이 였 다. 많은 쏘프트웨어 의 성 공에 대 한 이 야기 들이 있음에 도 불구하 
고 상당한 량의 쏘프트웨어 는 여 전히 뒤 늦게 예 산을 초월하여 그리 고 오유를 포함한 채 
로 배포되고 있다. 

쏘프트웨 어위 기 가 30년 이 지난 오늘도 여 전히 남아 있다는것 은 두가지 문제 점 을 말 
해 주고 있다. 첫째로 쏘프트웨어생산공정은 많은 측면에서 전통적인 공학과 류사하지만 
그자체의 고유한 특성과 문제점을 가지고 있다. 둘째로 쏘프트웨어위기는 그것이 장기성 
을 띠며 예측하기 어렵다는 관점으로부터 아마도 쏘프트웨어불경기라고 바꾸어 불러야 
할것 같다. 확실히 다리는 조작체 계만큼 자주 무너 지지는 않는다. 그러면 왜 다리건설기 
술이 조작체계구축에 리용될수 없는가? NATO 대회에서 스쳐 지나버린것은 분필이 치즈 
와 다른것처 럼 다리 가 조작체 계와는 다르다는 사실이 다. 

다리와 조작체계사이의 기본차이는 무너져 내리는 동작에 대한 일반공학자들의 집단 
과 쏘프트웨 어 공학자들의 집 단의 관점 에 있 다. 1940년 에 무너 져 내린 타코마의 좁은 다 
리와 마찬가지로 다리가 무너져 내리면 다리는 거의 모두 다시 설계하고 파괴된것을 다 
시 세워야 하였다. 원래의 설계는 잘못 된것이였고 인간의 안정을 위협하는것으로 하여 
설계는 철저히 바꾸어 지게 된다. 이 밖에 거의 모든 실례들에서 다리 가 무너져 내린 결 
과 다리 구조물에 너 무 많은 손상을 주기 때 문에 유일하게 합리 적 인 방도는 파괴 된 다리 의 
잔해를 파피해 버리고 그것을 완전히 다시 설계하고 건설하는것이다. 더우기 같은 설계 
로 건설된 다른 다리들은 주의 깊게 검사되여야 하며 최악의 경우에는 설계를 다시 하고 
다시 건설하여야 한다. 조작체계의 폭주는 범상치 않은 일로서 간주되며 드물게는 그 설 
계 에 대 한 즉시 적 인 조사를 진행하게 한다. 폭주가 발생하면 그 폭주를 초래한 조작환경 
이 재 발하지 않도록 하기 위하여 간단히 체계를 다시 초기 화하는것 이 가능할수도 있다. 
흔히 있는 경우이지만 폭주원인에 대한 근거가 밝혀 지지 않은 경우에는 그것이 유일한 
보수대책으로 될수 있다. 폭주로 인한 손해는 보통 어떤 자료기지가 부분적으로 손상되 
였든가 일부 파일이 잃어 진것과 갈은 부차적인것들이다. 지어 파일체계에 대한 손상이 
크다면 흔히 여 분의 자료는 파일체 계 를 선행한 폭주조건을 완전히 제 거하지 못한 어 떤 
상태 로 체 계를 회귀할수 있다. 아마도 일반공학자들이 다리의 파괴를 취급하는것처 럼 쏘 
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프트웨어공학자들이 조작체 계 를 심 중하게 취 급하면 쏘프트웨 어공학에 서의 전문화수준이 
자연적으로 올라 가게 될것 이다. 

이제 실시간체계 즉 실세계로부터 들어 오는 입력이 발생하자마자 곧 그 입력에 응 
답할수 있는 체계를 고찰해 보자. 한가지 실례로서 콤퓨터조종집중치료기를 들수 있다. 
사실상 아무리 많은 구급환자들이 동시에 발생한다고 하여도 체계는 상태가 위급하지만 
안정한 환자들을 감시하는것을 중단함이 없이 새로운 구급환자들에 대하여 주의를 돌릴 
것을 의료일군들에게 계속 경고해 야 한다. 일반적으로 집중치료기나 핵 반응로，우주정류소 
에서의 기후조건들을 조종하는것과 같은 실시간체계에서의 고장은 그 영향이 아주 크다. 
그러므로 대부분의 실시간체계들은 고장의 영향을 최소화하기 위하여 일련의 오유허용한 
계를 포함하고 있다. 즉 체계는 임의의 고장을 자동적으로 회복할수 있도록 설계된다. 

바로 오유허용한계에 대한 개념은 다리와 조작체계사이의 기본차이를 강조하고 있다. 
다리들은 강한 바람，불의의 큰물 등과 갈은 상당히 예측하기 어려운 조건들에 견디여 
낼수 있도록 설계된다. 

대부분의 쏘프트웨어작성자들이 전제로 하고 있는 하나의 절대적인 가정은 쏘프트웨 
어가 극복해야 할 가능한 모든 조건들을 예측할수 없으므로 예견하지 못한 조건으로부터 
초래되는 피해를 최 소화하도록 쏘프트웨 어를 설계 하여 야 한다는것 이 다. 

달리 말하면 다리는 완전하게 설계된다고 가정하며 반대로 대부분의 조작체계는 불 
완전하게 설계 된다고 가정 한다. 즉 대부분의 조작체 계 불은 재 초기 화조작이 사용자들이 
필요할 때마다 할수 있는 간단한 조작으로 되는것처럼 그러한 방식으로서 설계된다. 이 
러한 차이가 오늘날 그처럼 많은 쏘프트웨어를 왜 공학적으로 구성되였다고 볼수 없는가 
하는 기본리유로 된다. 

이와 갈은 차이는 다만 일시적이라고 볼수 있다. 결국 우리는 다리를 수천년동안 세 
워 왔으며 다리가 견디여 내야 할 각이한 류형의 조건들에 대하여 충분한 경험과 전문기 
술을 가지게 되 였다. 우리는 조작체 계 에 대 하여 다만 50여년간의 경 험을 가지 고 있을뿐 
이다. 우리가 더 많은 경험을 가지게 되면 명백히 우리가 다리를 리해하는것과 마찬가지 
로 조작체 계 를 리해하게 될 것 이 며 결 국은 오유가 없는 조작체 계 를 구성할수 있게 될 것 이 
라는 론리가 성립한다. 이러한 론의에서 약점은 하드웨어의 복잡성 그리고 그로 인하여 
조작체계의 복잡성이 그것 에 대한 파악가능성보다 더 빨리 증대된다는것이다. 1960년대 
에는 다중프로그람작성조작체 계를 가지 게 되 였고 1970년대 에는 가상기 억을 취 급하였으며 
이제는 다중처리기가 분산(망)조작체계에 자리를 양보하려 하고 있다. 우리가 조작체계와 
같은 쏘프트웨어제품을 구성하는 여 러 가지 구성요소의 호상결합으로 하여 생기는 복잡 
성 을 조종할수 있기전에 는 그것 을 완전히 리해할수 없다. 즉 리해하지 못하면 그것 을 
설 계할수 없 다. 

쏘프트웨어의 복잡성의 원인은 그것 이 실행될 때 불련속적 인 상태 로 동작한다는것 이 
다. 지 어 한비트만 변하여도 쏘프트웨어는 상태변화를 일으킨다. 이 러한 상태들의 총수는 
핑장히 많으므로 그 대 부분의 상태 를 개발림 에 서 다 고려 하지 는 못하였 다. 만일 쏘프트 
웨어가 이런 예측하지 못한 상태에 놓이게 되면 그 결과는 흔히 쏘프트웨어의 고장으로 
끝난다. 다리는 련속적인(상사적인) 체계이다. 그것들은 련속수학，본질적으로는 계산을 
리용하여 서 술된 다. 그러 나 조작체 계 와 갈은 불련속체 계 는 리 산수학을 리용하여 서 술되 
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여 야 한다 [ Pamas , 1990]. 그러 므로 쏘프트웨 어 공학자들은 이 와 같은 복잡성 을 처 리하려 고 
할 때 하나의 기본도구로 되는 리산수학에 정통하여 야 한다. 

다리 와 조작체 계 의 두번째 기 본차이 는 유지 정 비 이다. 어 떤 다리 를 유지 정 비하는것 은 
일 반적 으로 그것 을 장식하며 갈라 진 름을 수리 하고 도로를 다시 닦는것 등에 제 한되 여 
있 다. 일 반공학자들에 게 다리 를 90° 회 전시켜 달라고 하거 나 185 km 이 동시 켜 달라고 하 
면 그들은 무지 막지한 요구라고 생 각할수 있 다. 그러 나 묶음식 조작체 계 로부터 시 간분할 
조작체계에로 변환하거나 한 콤퓨터로부터 완전히 다른 구성특성을 가진 다른 콤퓨터로 
체계를 이식하기 위하여 쏘프트웨어공학자들을 요청할 일은 전혀 없는것 같다. 만일 어 
떤 조작체 계 를 새 로운 하드웨 어 에 이 식하는 경 우에 그 조작체 계 원천코드의 50%를 5년 
주기 로 재작성하는것 은 보통일 이다. 그러 나 공학자들중에 서 다리 의 절 반을 교체할수 있 
다고 생각하는 사람은 없을것이다. 즉 안전요구사항들에는 새 다리를 세울것을 지적하고 
있다. 그러므로 유지정 비령역은 쏘프트웨 어공학이 전통적 인 공학과 차이 나는 두번째의 
기본측면으로 된다. 쏘프트웨어공학에 대한 그밖의 유지정비측면에 대하여서는 1.3 에서 
서 술하고 먼저 경제 적 측면들에 대 하여 고찰하기 로 한다. 

1.2. 경제적인 측면 

화학공학과 화학사이 의 관계 를 비 교함으로써 쏘프트웨 어 공학과 를퓨터 과학사이 의 관 
계에 대한 견해를 가질수 있다. 결국 콤퓨터과학과 화학이 모두 과학이라는것은 그것들 
이 리론적인 구성요소와 실천적인 구성요소를 가지고 있기때문이다. 화학의 경우에 실천 
적인 구성요소는 연구사업으로 되지만 를퓨터과학의 경우에 실천적인 구성요소는 프로그 
람작성으로 된다. 

석 탄으로부터 휘 발유를 추출하는 공정 을 생 각해 보자. 제2차세 계 대 전기 간에 도이췰 
란드는 연유공급이 단절되였기때문에 자기들의 전쟁무기용연료를 만들기 위하여 이 공정 
을 리용하였 다. 

인종차별을 반대하는 원유봉쇄가 실시되는 동안 남아프리카공화국정부는《 남아프리 
카의 석 탄을 원유로 》 (South African Coal into Oil , SASOL ) 라는 계 획밑 에 1 조딸라를 쏟아 부 
었다. 남아프리카액체 연료수요의 약 절반이 이 방법으로 충당되 였다. 

어떤 화학자의 견지에서 보면 석탄에서 휘발유를 얻는데는 여러가지 방법들이 있는 
데 다같이 중요하다. 결국 그 어떤 화학반응도 다른 화학반응보다 더 중요하지는 않다. 
화학공학기사들의 견지에서 보면 어느 한때 석탄으로부터 휘발유를 합성해 내는 하나의 
중요한 수단 즉 경제적 으로 가장 인기를 끄는 하나의 반응은 명백 히 존재한다. 달리 말하 
면 화학공학기사들은 가능한 모든 반응들에 대하여 평가하고 그중에서 1/당 비용이 가장 
낮은 반응을 제 외 하고는 모두 버리 는것 과 갈다. 

를퓨터 과학과 쏘프트웨 어 공학사이에 도 이 와 같은 류사한 관계 가 있 다. 콤퓨터 과학자 
들은 좋은것 과 나쁜것 을 모두 포함하여 쏘프트웨어 를 생 산하기 위한 여 러 가지 방법 들을 
연구한다. 그러 나 쏘프트웨 어공학자들은 경계적 가치 가 있는 그러한 기 법들에만 흥미를 
가진 다. 


23 




실례로 현재 코드작성기법 CT cld 을 리용하고 있는한 쏘프트웨어기업체는 새로운 코 
드작성기법 CT new 가 CT cld 에 필요한 시 간의 9/10로 따라서 9/10의 비용으로 코드를 생성한 
다는것을 발견하였다. CT new 기술이 리용하기 적합한 기법이라는것이 공통적인 인식으로 
되는것 같다. 사실상 선택기법 이 보다 빠른 기법 이라는것 이 공통적 인 인식 인것 같지만 쏘 
프트웨어공학의 경제학은 그 반대사실을 나타낼수도 있다. 그 하나의 리유는 어떤 기업체 
가 새 로운 기 술을 도입할 때 드는 비 용으로 설 명할수 있 다. 

CT new 기 법 을 리용하게 되 면 코드작성 이 10% 더 빨라 진 다고 하는 사실 은 CT new 기 법 
을 도입하는데 드는 비 용에 비 하면 그리 중요하지 않을수도 있 다. 양성 에 필 요한 비 용을 
보상하기전에 2〜3개 의 프로젝 트를 완성하는것 이 필 요할수도 있 다. 또한 CT new 과정안을 
집 행하는 동안은 프로그람작성 자들이 생 산활동에 종사할수 없게 된다. 비 록 배 우고 돌아 
왔다 해 도 짧은 기 간에 급하게 배 워 왔으므로 쏘프트웨어 전문가가 (:孔^와 마찬가지 로 
CT new 에 숙련되 자면 몇달동안은 CT new 를 련습하여 야 할수도 있 다. 그러 므로 CT new 를 리 용 
하여 첫 프로젝 트를 완성하는데 는 (^^를 리 용할 때 보다 더 오랜 시 간이 걸 릴것 이 다. 
CT new 로 전환하겠는가를 결정할 때 이러한 비용에 관한 문제를 고려해야 한다. 

무엇때 문에 쏘프트웨 어 공학의 경제 적측면 이 CT cld 가 유지 되 여 야 한다는것 을 암시할 
수 있는가 하는 두번째 리유는 바로 유지정비의 결과이다. CT new 코드작성기술은 실지 
CT old 에 비하여 10% 더 빠를수 있다. 그 결과에 생성된 코드는 의뢰자들의 현재의 수요 
를 만족시 킬수 있는 품질을 가질수 있다. 그러 나 CT new 기술을 리용하면 제품의 사용기간 
보다도 CT new 값을 더 높게 설 정 함으로써 유지 정 비 하기 어 려 운 코드를 생 성할수 있 다. 물 
론 쏘프트웨어개발자들은 유지정비에 아무런 책임도 없다는 관점으로부터 CT new 가 가장 
매력이 있는 제안으로 된다. 결국 CT new 의 리용은 비용을 m% 로 더 적어 지게 한다. 의 
뢰자들은 CT dd 기 술을 리용할것 을 주장하며 따라서 쏘프트웨어 의 전체 적 인 사용기 간에 
드는 비용이 더 적어 질것 이라는 기대를 가지고 보다 더 높은 초기비용을 지불하여 야 한 
다. 의 뢰 자와 쏘프트웨어 제작자들의 유일한 목적 은 될수록 빨리 코드를 작성하는것 이 다. 
일반적으로 어떤 특정한 기법을 리용하는데 오랜 시간이 드는것은 단기리득의 리윤에 의 
하여 무시된다. 쏘프트웨 어 공학에 경제 적 인 원리 들을 적 용하는것 은 의 뢰 자들이 장기비 용 
을 감소시키 는 기 술을 선택할것 을 요구한다. 

1 . 3. 유지정비적인 측면 

개념의 구상으로부터 마지막 폐기에 이르기까지 쏘프트웨 어가 거치게 되는 매 단계 
들을 생 명 주기 (/^ cyc/e) 라고 부론다. 이 기 간에 제 품今 여 러단계 즉 요구사항확정，명 세 
작성，설계, 실현, 통합，유지정비，폐기단계를 거치게 된다. 생명주기모형에 대하여 제3장 
에서 보다 구체적 으로 론의한다. 여기 에서는 유지정 비의 개념을 정의 하기 위한 문제들을 
론의 한다. 

1970년대 말까지 대부분의 개 발기 업체 들은 현재 폭포모형 (mzter/a// wo 쇼/)이 라고 부르 
고있는 생명주기모형을 리용하여 쏘프트웨어를 개발하여 왔다. 이 모형에 대한 여러가 
지 변종들이 있는데 제품은 크게 7개의 기본적인 단계를 거처 개발된다. 이러한 단계들 
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은 어떤 특정한 기업체의 단계들에 정확하게 대응하지 않을수도 있지만 이 책이 목적하 
고 있는 실천에는 충분히 가깝다. 이와 류사하게 매 단계들에 대한 정확한 이름도 기업 
체에 따라 달리 불리우고 있다. 여러단계들에 리용되는 이름들은 독자들이 잘 리해할수 
있도록 될수록 일반적인것으로 선택하였다. 그림 1-1 에 매 단계들을 개괄하여 주고 그 
단계들이 제시되는 장들도 표시하여 주었다. 


1. 요구사항확정단계 ( m 장) 

2. 명 세작성 (분석 )단계 (11 장， U 장) 

3. 설계단계 (13 장) 

4. 실현단계 (14 장，15장) 

5. 통합단계 (15 장) 

6. 유지 정 비 단계 (16 장) 

7. 페 기 


그림 1-1. 쏘프트웨어생명주기의 단계와 해당한 장들 

1. 요구사함■확정단계 (요£우 w/rewe … jo / wwe ) 이 단계에서는 개념들을 찾아 내고 엄밀히 규 
정하며 의뢰자들의 요구를 도출 해 낸다. 

2. 명세작성(분석)단계 (* S^ec 與 caft ’ on ( ana />_) phase ) 이 단계에서는 의뢰자들의 요구를 
분석 하고 그것을 《 이 제 품은 무엇을 하기 로 제 안되 는가?》라는 명세서형 식 으로 제시한 
다. 이 단계를 때때 로 분석단계 라고도 한다. 이 단계의 마감에서 제 안된 쏘프트웨 어 개 발 
을 아주 상세 히 서술하고 있는 쏘프트웨 어 프로젝트관리 계 획(■비/ hwzre project management 
plan ) 을 작성 한다. 

3. 설계단계 (Z 切신 g « phase ) 명세서는 두개의 련속적인 설계과정을 거치게 된다. 첫째 
로 구성방식설계가 있는데 여기서는 제품을 모둘 ( moc / w / e ) 이라고 부르는 구성요소들로 제 
품전체 를 분할한다. 그다음 매 모둘이 설계 되 는데 이 과정 을 상세설계 라고 부론다. 이 
두개 의 설 계 문서 들은 《 제 품 이 어 떻 게 일 하는가?》를 서 술하고 있 다. 

4. 실현단계 phase ) 이 단계에서는 여러가지 구성요소들이 코드작성 되 

고 시험된다. 

5. 통합단계 (Tntegrafew phase ) 이 단계에서는 제품의 구성요소들이 전체적으로 결합 
되고 시험된다. 개발자들이 제품이 정확하게 기능을 수행한다고 생각하게 되면 그 제 
품은 의 뢰 자들에 의 하여 시 험 된 다(인수시 험 ; acceptance testing ). 제 품이 의 뢰 자들에 의 
하여 승인되고 를퓨터에 설치되게 되면 이 단계는 끝난다(통합단계는 실현단계와 병 
렬 로 수행 되 여 야 한다는것 은 제15장에 서 보게 된다.). 

6. 유지정비 단계 phase ) 제 품은 개 발목적 으로 한 과제 를 수행 하는데 
리용된다. 이 기간에 제품은 유지정비된다. 유지정비는 일단 의뢰자가 제품이 명세서에 
부합된다고 만족을 표시한후 그 제 품에 대 하여 진행하는 모든 변화를 포함하게 된다(다 
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음의 《알고 싶은 문제》를 보시오.). 유지정비에는 명세서에 대한 변경들과 그 변경들에 


알：2 싶은 寒지 I 

1970년대에 쏘프트웨어제품생산은 련속적으로 수행되는 두개의 구별되는 활동 즉 개발에 
뒤 이 은 유지 정 비 로 이 루어 진다고 간주되 였 다. 쏘프트웨어 제 품은 령 상태 에 서 개 발된 1 -음 의 
뢰자의 콤퓨터들에 설치되게 된다. 잔류오유를 수정하든가 기능을 확장한다든가 등 요 프트웨 
어제품이 설치된후에 진행되는 모든 변경들이 고전적인 유지정비를 이룬다 [IEEE 610.2, 
1990]. 그러 므로 쏘프트웨어 가 고전적 으로 개 발되 는 방식 을 선 개 발후유지 정 비 (쇼 ve / wne 射- 
then - maintenance ) RJ ^ °1 말할수 있 다. 

이것은 일시적 인 정의 에 지 나지 않는다. 다시 말하여 활동은 그것 이 진행되는 시점| I 따라 
서 개 발 또는 유지정 비로 구별된다. 이제 쏘프트웨 어 가 설치된후 어느 날 오유가 발견: 여 정 
정된다고 가정하자. 이것은 명백히 유지정비로 된다. 그러나 쏘프트웨 어가 설치되기전< 우와 
같은 오유가 발견되 여 정정된다고 하면 이것은 고전적 인 정의 에 의하여 개 발로 된다. 

다음의 두가지 리유로 하여 이러한 모형은 오늘날에 와서 비현실적인것으로 된다. 첫째로 
요즘 하나의 제 품을 개 발하는데 %».보통 1년 또는 그이 상 시 간이 걸 린 다. 이 기 간에 의 로 자들의 
요구는 변화될수도 있다. 실례로 의뢰자는 쏘프트웨어제품이 리용가능한 보다 더 빠른 처리기 
에서 실현될것을 주장할수도 있다. 한편 제품이 개발되는 도중에 의뢰자측은 카나다로 확장되 
여 이제는 제품이 카나다에서도 판매를 실현할수 있도록 수정되여야 할수도 있다. 요국 4항에 
서의 이러한 변화가 쏘프트웨어생명주기에 어떤 영향을 미치는가를 보기 위하여 설계가 진행되 
고 있는 동안 의뢰자들의 요구사항이 변화된다고 가정하자, 쏘프트웨어개발림은 개발을 중지하 
고 변화된 요구사항을 반영하여 명세서를 수정하여야 한다. 더우기 만일 명세서에 대한 련경이 
이미 완성된 설계의 부분들에 대하여 해당한 변경을 진행할것을 요구한다면 그때는 설: I 도 물 
론 수정되여야 한다. 이러한 변경이 다 진행되였을 때에만 개발을 계속 진행할수 있다. : 卜리 말 
하여 개 발자들은 제 품이 설치되기 전에 오래 동안《유지 정비》를 진행 하여야 한다. 

둘째 로 고전적 인 선개 발후유지 정 비 모형 에서 쏘프트웨 어 를 개 발하는 방법 상의 문 태 로써 
제기된다. 고전적인 쏘르트웨어공학에서 개발의 특징은 개발림이 목적하는 제품을 령 y ■태에 
서부터 개 발한다는것 이 다. 이와 대조적 으로 오늘날 쏘프트웨 어 생산의 비용이 높아 지 는것과 
관련하여 개발자들은 개발되여야 할 쏘프트웨어에서 될수록 현존쏘프트웨어제품의 일 부분을 
재리용하려고 하고 있다(재리용에 대하여서는 제8장에서 자세히 서술한다.). 따라서 社개발 
후유지정비모형은 재리용이 진행될 때에는 적합치 않다. 

유지정비를 고찰하는데서 보다 더 현실적인 방도는 유지정비를 《쏘프트웨 어가 대선이 
나 적응과 관련한 어떤 문제나 요구로 하여 코드 또는 그와 관련한 문서들에 대한 r 정을 
거치게 된다.》고 할 때 일어 나는 과정으로 간주하는것이다 [ ISO/IEC 12207,1995], 이 정의에 
따르면 제품이 설치되기전이나 설치된 다음에 진행하는가에 관계없이 오유가 수정되: 나 오 
유가 변화될 때마다 유지정비가 진행된다. 

그러 나 대 부분의 쏘프트웨 어 공학자들이 선개 발후유지 정 비 모형 이 시 대 에 뒤 떨 어 진 3 이 라 
는것 을 깨 닫게 되 기 전까지 는 단어 유지 정 비 ( wa /« te « ce ) 의 리 용을 달리 하는데 는 거 의 - -제 가 
없다. 이 책 에서는 제품이 완성되 여 설치된 다음에 진행하는 유지정 비 에 대 하여 언급; •기 로 
한다. 그러 나 유지정 비의 실제적 인 본질은 곧 보다 더 광범하게 인식될것 이 라고 생각 i •다. 
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대한 실현으로 이루어 지는 확장(또는 쏘프트웨어갱신)은 물론 명세서를 변화시키지 
않은채 잔류오유들을 제거 하는 교정유지정 비(또는 쏘프트웨 어수정)가 포함된다. 

확장에는 두가지 류형 이 있다. 첫째는 완전유지정비 maintenance ) 즉 추가적 
인 기 능 또는 감소된 응답시 간과 같이 의 뢰 자가 제 품의 효과성 을 개선하기 위하여 진행 
하는 변경 들이 다. 둘째 는 적 응유지 정 비 ( acfopft’ve maintenance ) 즉 새 로운 관리 조절과 같이 
제품이 동작하는 환경 에서의 변화에 대 하여 만들어 진 변경들이다. 연구결과는 유지정 비 
성 원들이 평 균적 으로 교정유지 정 비 에 약 17.5%, 완전유지보에 60.5%, 적 응유지 정 비 에 
18% 정 도의 시 간을 소비하게 된 다는것 을 보여 주었 다. 

7. 페 기 (及如射) 이 단계 에서 제품은 봉사로부터 제거된다. 페기는 그 제품이 
제 공하는 기 능이 더 이 상 의 뢰 자측에 아무런 쓸모도 없는 경 우에 발생한다. 

유지정 비의 론점 으로 되돌아 가서 보면 때때 로 나른 쏘 프트웨 어제품만이 유지정 비 를 
거처야 한다고 한다. 사실상 그 의견은 옳다. 즉 나른 제품은 버러 지고 반면에 좋은 제 
품은 약 10, 15 지 어 20년까지 도 수리 되 고 기 능이 확대 된 다. 더우기 하나의 쏘 프트웨 어 제 
품은 현실세 계 에 대 한 하나의 모형이며 현실세계 는 끊임 없이 변화되 게 된다. 결국 쏘프 
트웨 어 는 현실세 계 를 정 확히 반영하도록 끊임 없 이 유지 정 비 되 여 야 한다. 

실례 로 판매세 금률이 6%에서 7%까지 변하면 구매 또는 판매를 처 리하는 거의 모든 
쏘 프트웨 어제 품들은 변경 되 여 야 한다. 제 품이 C ++ 명 령 


const float salesTax = 6.0 


을 포함하거 나 그것과 동등한 Java 명 령 


public static final float salesTax = (float) 6.0; 

을 포함한다고 하자. 여기서 이 명령은 salesTax 는 값 6.0 으로 초기화된 류동소수점상수라 
는것을 선언하고 있다. 이 경우에 유지정비는 비교적 간단하다. 본문편집기로 값 6.0 을 
7.0 으로 교체 하고 코드를 다시 콤파일 하고 련 결한다. 그러 나 만일 판매세 금의 값이 호출 
될 때 마다 이 름 salesTax 대 신에 실제값 6.0 이 이 제 품에서 리용되 였 다면 그러한 제 품은 
유지정비하기가 아주 어렵게 된다. 실례로 원천코드에서 7.0 으로 변경되여야 하지만 스쳐 
보낸 값 6.0 이 있을수도 있고 또는 판매세금과는 관계가 없지만 부정확하게 7.0 으로 변경 
되는 값 6.0 이 있을수도 있다. 이러한 오유를 찾는것은 거의 언제나 어렵고 시간이 많이 
소비된다. 사실상 어떤 쏘프트웨어 에서는 많은 상수들가운데서 어 느것 이 변경되 여 야 하 
며 또 그 변경을 어떻게 진행하겠는가를 결정하려고 하는것보다 그 제품을 버리고 다시 
코드작성하는것 이 시 간이 적 게 걸릴수도 있 다. 실시 간적 인 현실세 계 는 끊임 없 이 변화한 
다. 어 떤 분사식전투기 들에 장비 된 미싸일들은 련관된 항공전자설 비체 계의 무기조종요소 
들을 변화시킬것을 요구하므로 새로운 모형으로 교체되게 된다. 일반적 인 4기통자동차들 
이 6기통기관으로 교체되게 된다. 즉 이것은 연료분사식체계와 시간계수기 등을 조종하 
는 자동차에 장비 된 콤퓨터 를 변경 시 켜 야 한다는것 을 의 미한다. 건전한 개 발기 업 체 들은 
변경되지만 사멸하는 개 발기 업체 들은 더 이상 발전하지 않는다. 이것은 확대형 식의 유지 
정비가 개발기업체가 살아 움직인다는것을 보여 주면서 개발기업체의 활동에 긍정적인 
기 여를 한다는것 을 의미한다. 그러 면 유지정 비하는데 얼마나 많은 시 간이 걸리 겠는가? 
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그림 1-2 에 있는 파라다임도표는 문헌 [ Elshoff , 1976; Daly , 1977; Zelkowitz , Shaw , and 
Gannon , 1979; and Boehm , 1981] 을 비 롯한 각이 한 자원들로부터 얻 은 자료를 평 균하여 
얻어 낸것이다. 그림 1-2 는 쏘프트웨어생명주기의 매 단계에서 소비되는 시간 (= 비용)에 
대한 근사적인 퍼센트를 보여 주고 있다. 약 15년후에도 여러 개발단계들에 지출되는 시 
간비률은 거의 변화되지 않았다. 이것을 그림 1-3 에 제 시하였는데 여 기서는 그림 1-2 에 
있는 자료를 132개 훌레트-패카드 ( Hewlett - Packard ) 프로젝트들의 최신자료와 비교하고 있 
다. 그림 1-2 에 나오는 자료는 보다 새로운 자료와 비교할수 있도록 분할되였다;° 



그림 1-2 에 보여 준바와 같이 전체 쏘프트웨 어비 용의 약 2/3가 유지 정 비 에 돌려 진다. 
최근의 자료들은 유지정비의 중요성에 대하여 계속 강조하고 있다. 실례로 1990년에 흘레 
트-패 카 드회 사 에서의 연구 및 개발성원들중 60〜80%는 유지정비에 종사하였으며 
유지 정 비 에 드는 비 용은 쏘프트웨 어 의 전체 비 용의 40〜60%에 달하였 다 [ Coleman , Ash , 
Lowther , and Oman , 1994]. 그러 나 많은 개 발기 업 체 들에 서 는 시 간과 노력 의 80%정 도를 
유지정비 에 돌리고 있다 [ Yourdon , 1996]. 그러므로 유지정비는 쏘프트웨 어생명주기 가운데 
서 매우 많은 시간을 소모하는 단계로 된다. 

이제 현재 코드작성 기법 (:孔^를 리용하고 있는 쏘프트웨어 기업체들에서 CT new 가 코 
드작성 시 간을 약 10% 감소시키 게 될 것 이 라는것 을 들은 경 우를 다시 고찰해 보자. 비 록 
CT new 가 유지 정 비 에 전혀 역 작용을 하지 않는다 할지 라도 예 민 한 쏘프트웨 어관리 자는 코 
드작성실행 을 바꾸기전에 다시 한번 생각할것 이 다. 전체 성 원들은 구입한 새 쏘프트웨 어 
개발도구에 숙련되여야 할것이며 아마도 새 기법에 경험이 있는 성원들을 보충해야 할수 


이 그림 1-3 은 다만 개 발단계 를 반영 하고 있다. 그림 1-2 에 있는 요구사항확정과 명세작 
성 단계들에 드는 개 발시 간의 몫은 그림 1-3 에 보여 준바와 같이 (2+5)/33 또는 21%이 다. 
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도 있 다. 이 모든 비 용과 재 조직 은 쏘프트웨 어비 용에 서 가능한껏 0.5% 정 도 감소시 켜 야 
한다. 왜 냐하면 그림 1-2 에 보여 준바와 같이 모둘코드작성 은 전체 쏘프트웨 어비 용에 서 
평 균 5% 정 도만을 이 루고 있 기 때 문이 다. 



1976 년과 1981 년사이의 
프로젝트 

흘레 트-패 카드회사의 
최근 132 개 프로젝트 

요구사항확정 단계 와 
명세 작성 (분석)단계 

21% 

18% 

설 계 단계 

19 

18 

실현단계 

34 

36 

통합단계 

29 

24 


그림 1-3. 1976년과 1981년사이 여러가지 프로젝트들과 흘레트-패카드회사의 최근 132개 
프로젝 트의 개 발단계 에 따르는 시 간소비 의 대 략적 인 평 균퍼 센 트비 교 

이제 유지정 비비 용을 10%로 줄이는 새 기술이 개 발되 였 다고 하자. 이것은 아마 즉 
시에 도입되게 될것이다. 왜냐하면 전체적인 비용이 평균적으로 약 6.7% 정도 감소될수 
있기때문이다. 이러한 기법으로 전환하는데 드는 무익한 시간은 그러한 큰 규모의 전면 
적 인 절약에 적은 비용을 지불하는것으로써 보상된다. 

유지정비가 이처럼 중요하기때문에 유지정비의 비용을 줄이는 기법이나 도구，실천 
은 쏘프트웨어공학의 중요한 측면을 이루게 된다. 

1.4. 명세작성 및 설계측면 

쏘프트웨 어전문가들도 사람인것만큼 때 때로 제품을 개 발하는데서 오유를 범하게 
된다. 결과 쏘프트웨어에 오유가 있게 된다. 만일 요구사항확정단계에서 오유가 생기 
게 되면 그로부터 초래되는 오유는 명세작성과 설계 그리고 코드에 반영되게 된다. 
오유를 제때 에 수정 할수록 더 좋다는것은 명백 하다. 쏘프트웨 어생명주기의 여 러 단계들 
에 서 오유를 수정하는데 드는 상대 적 인 비 용들을 그림 1-4 에 보여 주었 다 [ Boehm , 
1981]. 이 그림은 IBM [ Fagan , 1974], GTE [ Daly , 1977], 보호프로젝트 [ Stephenson , 1976] 
그리 고 어 떤 소규모 TRW 프로젝 트 [ Boehm , 1980] 에 서 의 자료를 반영 하고 있 다. 

그림 1-4 에서 실선은 보다 큰 프로젝트와 관련되는 자료들에 가장 적합한것이고 점 
선은 보다 작은 프로젝 트와 관련된 자료들에 가장 적 합한것 이 다. 쏘프트웨 어생 명주기의 
매 단계 들에 서 오유를 발견 하고 정 정하기 위한 대 응하는 상대비 용들을 그림 1-5 에 보 
여 주었다. 그림 1-5 에 있는 실선에서 매 계단은 그림 1-4 의 실선우에서 대응하는 점 
들을 취 하고 선형축척 으로 자료들을 찍 음으로써 구성 되 였 다. 
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오4«견 寶 수과단채 


그림 1-4. 쏘프트웨 어생명주기의 여 러단계 에서 오유를 수정하는데 드는 상대적 인 비용 
실선은 보다 큰 쏘프트웨 어프로젝트와 관련한 자료이며 점선은 
보다 작은 쏘프트웨어프로젝트와 관련한 자료이다. 

(Prentice Hall , Inc ., Englwood Cliffs , NJ 의 허 락을 받은 배 리 보엠 의 
Software Engineering Economic , ©1981 , 40페 지 ) 

설 계 단계 에 서 어 떤 특정한 오유를 발견하고 정 정하는데 40딸라의 비 용이 들었 다고 
가정 하자. 그림 1-5(1974 년과 1980년사이에 있는 프로젝 트)에 있는 실선으로부터 명세작 
성 단계 에 서 그와 같은 오유를 수정하는데는 약 30딸라 소비 되 였 다. 그러 나 유지 정 비단계 
에서 는 그러한 오유를 찾아 내 고 수정하는데 는 약 2,000딸라가 들었 다. 이 자료는 오유를 
빨리 찾아 내는것 이 매우 중요하다는것을 보여 준다. 

그림 1-5 에서 점 선은 IBM AS /400 에 대 한 체 계프로그람개 발과정 에 제 기된 오유를 발 
견 하고 수정 하는데 든 비 용을 보여 준다. 평 균적 으로 AS /400 쏘프트웨 어 의 유지 정 비 단계 
에서는 그와 같은 오유를 수정하는데 3,680딸라의 비 용이 들었다. 

어 떤 오유를 정 정하는데 드는 비 용이 그렇 게 급격 히 늘어 나는 리 유는 바로 오유를 
정 정하기 위하여 무엇 을 해 야 하는가 하는것 과 관련된 다. 개 발생 명 주기 의 초기 에 제 품은 
본질상 종이 우에 존재할뿐이였고 오유를 정 정하는 작업 은 지 우개 와 연필 을 가지 고 간단 
히 진행할수 있었다. 또 다른 극단은 제 품이 이미 의뢰 자에게 배포된 경우이 다. 적 어도 
오유를 정 정한다는것 은 코드를 편집 하고 그것 을 다시 콤파일 하여 련결 하고 그다음 문제 
가 해 결된다는것 을 주의 깊게 시 험한다는것 이 다. 다음으로 변경 을 진행하는것 이 그 제 품 
의 다른 곳에 어떤 새 로운 문제를 발생시키지 않았다는것 이 아주 중요한 문제 이 다. 그다 
음 지도서를 비롯한 련관된 문서들이 모두 갱신되여야 한다. 마지막으로 정정된 제품이 
배포되여 설치되여야 한다. 
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그림 1-5. 실선은 그림 1-4 에 있는 선형의 실선에 있는 점들을 나타낸다. 
점선은 보다 새로운 자료를 나타낸다. 


이로부터 엄게 되는 교훈은 다음과 갈다. 즉 오유는 될수록 빨리 찾아야 하며 오유 
를 정 정하는데 는 자금이 든다는것 이 다. 따라서 요구사항확정 과 명세작성(분석 )단계 에 서 
오유를 발견하기 위한 기 법 들을 소유해 야 한다. 이 런 기 법 들은 더 욱더 절실 히 요구된다. 
연구결 과는 큰 규모의 프로젝 트에 서 발견된 모든 오유의 60〜70%가 명 세작성 이 나 설 계 
상의 오유였 다는것 을 보여 주었 다. 보다 새 로운 결 과는 명 세작성 과 설 계 상의 오유가 더 
크다는것을 확증해 주었다. 검 토는 어떤 림 이 작성한 문서 에 대 한 주의 깊은 시험 이 다 
(6.2.3). 태 양계 의 우주공간프로그람을 무력하게 만드는 NASA 의 분사식 추진기연구쏘프트 
웨어에 대하여 203개의 검토를 진행하는 기간에 평균 페지당 오유가 명세서에서는 약 
1.9 개，설계에서는 0.9 개，코드에서는 0.3 개가 발견되였다 [ Kelly , Sherif , and Hops , 1992]. 
따라서 명세작성 및 설계기 법을 개선하는것 이 중요하다. 그리하여 될수록 빨리 오유를 
발견하여 야 한다. 왜 냐하면 명세작성과 설계 에서의 오유가 모든 오유들가운데서 큰 몫을 
차지 하기때 문이 다. 유지정 비비용을 10% 감소시키면 총체적 인 비 용은 거의 7% 감소될것 
이 라는것 을 보여 준 앞부분의 설계 에서 와 마찬가지 로 명세작성 과 설계오유를 10% 감소 
시키면 오유의 총 개수가 6-7% 감소될것 이 다. 

여 러가지 프로젝트들에 대한 새로운 자료들이 문헌 [Bhandari et al ., 1994] 에 서술되 
였다. 실례 로 콤파일 러는 방대한 변화를 거 치 였다. 설계 단계의 마감에서 프로젝 트개 발기 
간에 발견된 오유는 분류되였다. 13%의 오유만이 이전의 판본의 콤파일러들에서부터 이 


31 





전되 여 왔다. 나머 지오유가운데서 16%는 명세작성단계 에 서，기%는 설계 단계 에 서 인입 되 
였다. 쏘프트웨 어생명주기의 초기 에 그렇게 많은 오유들이 인입된것은 쏘프트웨 어공학의 
또 하나의 중요한 측면을 강조하고 있다. 즉 보다 좋은 명세와 설계를 생성하는 기 법들 
을 강조하고 있다. 

대부분의 쏘프트웨 어는 개발 및 유지정비단계를 책임진 개별적 인 사람들이 아니라 
쏘프트웨 어공학개발림 들에 의하여 개 발되게 된다. 이제 이 의미를 고찰해 보자. 

1. 5. 개발팀프로그람작성측면 

어떤 콤퓨터의 성능 - 비용인자는 다음과 같이 정의될수 있다. 

성능 - 비용인자 = 백만개의 더하기를 수행하는 시간 冷' 

CPU 와 주기억 의 가격 

이 값은 새세대 콤퓨터들의 출현과 함께 감소되였다. 이러한 감소는 전자공학 특히는 
3극소자와 대규모집적회로 ( VLSI ) 기술이 발견된 결과에 이루어 진것이다. 이러한 발견결 
과로 개발기 업체들은 큰 제품들 즉 허용된 시간제 약내 에 한사람이 작성 하기에는 너무 큰 
제품들을 동작시 킬수 있는 하드웨 어를 제공할수 있었다. 실례 로 어떤 제품이 18개월 이내 
에 배 포되 여 야 하는데 한명 의 프로그람작성 자가 그것 을 15년동안 완성해 야 한다면 그러 
한 제 품은 개발림 에 서 개 발하여 야 한다. 그러 나 개 발림 프로그람작성 은 코드구성 요소들사 
이 의 결 합문제 와 개발림 성 원들사이 의 통신문제 를 야기 시 킨다. 

실례로 죠 ( Joe ) 와 프레다 ( Freda ) 가 각각 모둘 p 와 다를 코드작성하는데 여기서 모둘 p 
는 모둘 q 를 호출한다. 모둘 p 를 작성할 때 죠는 인수목록에 5개 의 인수를 가지 고 q 에 
대 한 호출을 하게 된 다. 프레다는 5개 의 변수를 가지 고 코드 q 를 작성하였 지 만 죠가 한 
것과는 다른순서 로 하였다. 함수원형 을 리용하지 않으면 이것은 ANSI C 를파일 러 에서 발 
견되지 않을것이다. Java 해석기와 적재프로그람, C 에서의 / mr (8.7.4) 또는 Ada 의 련결프로 
그람과 같은 일부 쏘프트웨어도구들은 오직 호상교환변수들의 형 이 다를 때 에만 이 러한 
형위반을 발견할수 있다. 즉 그것들의 형이 갈으면 오랜 기간 문제가 발견되지 않는다. 
이것은 설계상의 문제이라고 론의되였으며 만일 모둘이 주의 깊게 설계되면 이 문제는 
제 기되지 않는다. 이것은 사실 이 나 실천적 으로 설계 는 흔히 코드작성 을 개시한 다음에 
변화되 는데 그러한 변화에 대 한 통보는 개발림 의 모든 성 원들에 게 배 포되 지 않을수도 있 
다. 이 리하여 둘이 상의 프로그람작성 자들이 작업하는 설계 가 변화될 때 불충분한 통신은 
죠와 프레다가 체험한 결합문제들을 초래할수 있다. 큰 제품을 실행할수 있는 강력한 를 
퓨터들이 제공될수 있게 되기전과 마찬가지로 다만 한명의 개발성원이 제품의 모든 측면 
을 책임지게 되는 경우에는이러한 문제가 덜 발생할수도 있다. 

그러 나 결 합문제 는 개발림 이 쏘프트웨어 를 개 발할 때 생겨 날수 있는 문제 들에 비 하 
면 빙 산의 일 각에 지 나지 않는다. 개발림 이 합리 적 으로 조직 되 지 않으면 개발림 성 원들사 
이의 협력에 지나치게 많은 시간이 랑비될수 있다. 제품이 단 한명의 프로그람작성자에 의 
하여 1년동안에 완성된다고 가정하자. 만일 같은 과제를 3명의 프로그람작성자들로 조직된 
개발림 에 게 맡긴 다면 그 과제 를 완성하는데 4개 월 이 아니 라 1년까지 걸 릴수 있 으며 결 과 
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코드의 품질은 전체적인 과제를 한명에게 맡기는것보다 더 떨어 지게 될것이다. 오늘날 쏘 
프트웨 어의 많은 부분은 개 발림 에 의 하여 개 발되고 유지정 비되 기때 문에 쏘프트웨 어공학의 
범위는 개발림이 합리적으로 조직되고 관리될것을 담보하는 기법들을 포함하여야 한다. 

앞절들에서 보여 준바와 같이 쏘프트웨어공학의 범위는 아주 넓다. 그것은 요구사항 
확정단계 로부터 시 작하여 폐 기단계 에 이르기 까지 쏘프트웨 어생 명주기의 모든 단계들을 
포함하게 된다. 그것은 또한 개발림과 갈은 인간적인 측면들과 경제적인 측면，저작권법 
과 갈은 법률상의 측면을 포함하게 된다. 이 모든 측면들은 이 장의 첫 부분에서 준 쏘 
프트웨어공학의 정의에서 명백히 구체화되였다. 즉 쏘프트웨어공학은 제때에 주어 진 예 
산내에서 사용자들의 수요를 만족시키면서 배포되는 오유 없는 쏘프트웨어제품을 개발하 
는것을 목적으로 하는 학문이다. 


1.6. 객체지향파라다임 

1975년이전에는 대부분의 쏘프트웨어기업체들이 특정한 기법을 리용하지 않았다. 즉 
개별적으로 자기식대로 연구를 진행하였다. 기본돌파구는 1975년부터 1985년사이에 이른 
바 구조화파라다임 이 개 발되면서 이 루어 졌다. 구조화된 파라다임 을 구성하는 기 법 에는 
구조화체 계 분석 (11.3) 과 자료흐름분석(7.1)，구조화프로그람작성과 구조화시 험 (14.8.2) 들이 
포함된다. 이러한 기법들이 처음 리용될 때는 아주 전망적인것 갈았다. 그러나 시간이 지 
남에 따라 성공적이지 못하다는것이 두가지 측면에서 증명되였다. 그것은 첫째로 그 기 
법 들은 때때 로 쏘프트웨어 제품의 크기 가 증대 됨 에 따라 그에 대 처할수 없 다는것 이 다. 즉 
구조화기법은 5,000 또는 50,000행이나 되는 코드를 가진 제품을 취급할 때는 충분하였다. 
그러 나 오늘 50만행 이 나 되는 코드를 포함하는 제품들은 크다고 간주되지 않는다. 지 어 50 
0만행 이상되는 코드를 가진 제품도 드물지 않다. 구조화기술은 흔히 오늘날의 큰 제품들을 
관리할수 있을 정 도로 확장되 지 않을수도 있 다. 

유지 정 비단계 는 구조화파라다임 을 더 이 상 기 대할수 없도록 하는 두번째 령 역 으로 된 다. 
30여년전 구조화파라다임 을 개 발하여 야 하였 던것 은 평 균쏘프트웨 어 예 산의 2/3가 유지 정 비 
에 돌려 지고 있었기때문이다(그림 1-2). 그런데 구조화파라다임은 이러한 문제를 해결할수 
없었다. 즉 1.3 에서 지적한바와 같이 많은 개발기업체들은 여전히 유지정비에 80%의 시간과 
노력 을 돌리 고 있다 [ Yourdon ^ 1996]. 

구조화파라다임이 크게 성공하지 못한 리유는 구조화기법이 행동지향적기법이나 또 
는 자료지 향적기 법 으로는 되지만 두가지 기 법을 모두 지 향하지는 않기때문이 다. 쏘프트 
웨어제품의 기본구성요소는 제품의 작용성들과 그 작용들이 조작하는 자료들이다. 

실례로 평균높이를 결정한다 (determine average height ) 는 높이(자료)들의 모임에 대하 
여 조작을 진행하고 그 높이(자료)들의 평균값을 귀환하는 작용이다. 자료흐름분석 (13.3) 
과 갈은 일부 구조화기법들은 작용지향적이다. 즉 이러한 기법들은 제품의 작용들에 주 


一 이 책 에서 는 쏘프트웨 어 개 발공정 (_ sq/hwe pracaw ) 이 라는 용어 와 혼돈을 피 하기 위 하여 
오히려 작용 ( acrton ) 이라는 단어를 리 용한다. 
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목하고 있 다. 즉 자료의 중요성은 2차적인것으로 된다. 반대로 잭 슨 ( Jackson ) 체계개발 
(13.5) 과 갈은 기법들은 자료지향적이다. 여기서는 자료에 중점을 둔다. 즉 자료에 대한 
작용에는 큰 의의를 부여하지 않는다. 

이 와 대 조적 으로 객체지향파라다임 에서는 자료와 작용을 다같이 중요하게 보고 
있다. 어떤 객체를 고찰하는 가장 단순한 방법은 객체를 자료와 그 자료에 대한 작용 
을 모두 병합하고 있는 하나의 통합된 쏘프트웨어구성요소로 보는것이다. 이러한 정의 
는 완전하지 않은데 이 책의 뒤부분에서 일단 계승(切뇨 이 정의되면 (7.7) 다시 

정의될것이다. 그러나 이 정의는 객체의 본질에 대하여 많은것을 말해 주고 있다. 객 
체에 대한 한가지 실례로 은행업무를 들수 있다(그림 1-6). 이 객체의 자료요소는 회 
계 맞추기 ( accow «/ 6 a / a « ce ) 이 다. 회 계 맞추기 에 대 하여 수행 할수 있는 작용들은 예 금 
( deposit ), 반환금과 잔고결정 6 a / a « ce ) 들이 다. 구조화파라다임 의 관 

점에서 보면 은행업무를 취급하는 제품은 하나의 자료요소 회계맞추기와 세개의 작용 
예 금, 반환，잔고결정 을 통합하여 야 한다. 객체지향관점 에서 보면 은행 업무는 하나의 
객체로 된다. 




그림 1-6. 구조화파라다임 (1) 과 객체지향파라다임 ( L ) 을 리용한 은행업무실현에 대한 비교 
객 체 를 둘러 싼 검 은 실선은 회 계 맞추기 를 어 떻 게 실현하는가에 대 한 세 부에 
대 하여 서 는 객 체밖에 서 는 알수 없 다는것 을 보여 준다. 

이 객체는 자료요소와 그 자료요소에 대하여 수행되는 세개의 작용들을 하나의 단위 
로 결합하고 있다. 

지금까지는 이 두가지 방법사이에 약간 차이가 있는것 같다. 그러나 중요한 점은 어떤 
객체가 실현하는 방식에 있다. 특히 어떤 객체의 자료요소가 어떻게 기억되는가에 관한 
세부들은 그 객체의 외부에는 알려 지지 않는다. 이것이 《정보은페 (여/ hiding )} 
의 한가지 실례인데 이것에 대하여서는 7.6 에서 더 자세히 론의한다. 그림 1-6 의 니에서 
보여 준 은행업무객체의 경우에 이 쏘프트웨어제품의 나머지부분은 은행업무객체내에서 
의 잔고와 같은것이라는것을 알수 있지만 회계맞추기의 형식에 관해서는 그 어떤 개념도 
가질수 없다. 즉 이 객체의 밖에서는 회계맞추기가 옹근수로 실현되는가 또는 류동소수점 
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으로 실현되는가를 전혀 알수 없다. 객체를 둘러 싼 이러한 정보장벽은 그림 1-6 의 니에 
서 검은 실선으로 표시되는데 그것은 객체지향파라다임을 리용한 하나의 실현에 대하여 
설명하고 있다. 반대로 그림 1-6 의 자)에서 회계맞추기는 점선으로 둘러 싸여 진다. 왜냐하 
면 회계맞추기의 모든 세부들이 구조화파라다임을 리용한 실현에서 모둘로 고찰되며 회계 
맞추기의 값이 그중 어느 한 모둘에 의하여 변화될수 있기때문이다. 

그림 1-6 의 !_) 의 객체지향실현을 고찰하면 만일 손님 이 하나의 계산서 에 10딸라를 
예 금하면 회 계 맞추기 자료요소(속성 ; attribute ) 에 m 딸라를 불무어 주라는 하나의 통보 
( massage ) 가 련관된 객체의 예금작용(방법 ( me 功 oc /)) 에 보내진다. 예금 ( cfe/w 해)방법은 은행 
업무객체내 에 있으며 회 계맞추기 가 어 떻게 실현되는가를 알고 있다. 이것은 객체안에서 
점선으로 지적되고 있다. 그러나 이 객체밖의 그 어떤 실체도 이러한 지식을 가지고 있 
을 필요가 없다. 

그림 1-6 의 L ) 에 있는 세개의 방법 이 회 계맞추기 를 제품의 나머지부분으로부터 차 
단하고 있는것은 이러한 지식의 국부화를 보여 주고 있다. 

얼핏 보기에는 실현세부들이 어떤 객체에 국부적이라는 사실이 그리 쓸모 있는것 
같지 는 않을수도 있 다. 우선 은행 업 무에 관한 제 품이 구조와 파라다임 을 리용하여 구 
축된 다고 하자. 만일 회 계맞추기 를 표시하는 방법 이 하나의 옹근수로부터 하나의 구조 
체마당으로 변화되 게 되 면 회 계맞추기 와 함께 진행 되 는 제 품의 모든 부분이 변화되 게 
되며 이때 이러한 변화들은 모순이 없이 진행되여야 한다. 반대로 객체지향파라다임이 
리용된다면 다만 은행 업 무객 체 그자체 내 에서만 변화가 진행 되 게 될것 이 다. 제 품의 다른 
부분들은 회계맞추기가 어떻게 실현되는지 알지 못하며 따라서 기타 다른 부분들은 회계 
맞추기를 호출할수 없다. 따라서 은행업무제품의 기타 다른 부분들은 변경될 필요가 없 
다. 결국 객체지향파라다임 은 유지정 비 를 보다 빨리 보다 쉽게 할수 있게 하며 회귀오유 
(즉 제품의 다른 부분에 명백 히 상관이 없는 변경을 진행한 결과에 그 제품의 어느 한 
부분에 본의아니게 인입된 오유)의 발생 은 크게 줄어 들게 될것 이 다. 

유지정 비의 우월성외 에도 객체지향파라다임은 개 발을 보다 쉽 게 할수 있게 한다. 많 
寒 실례들에서 하나의 객체는 어떤 물리적인 등가물을 가진다. 실례로 은행업무제품에서 
대상 은행업무 (bank account ) 는 은행에서의 실제적인 은행업무에 대응한다. 제 12장에서 보 
여 주는바와 같이 모형화는 객체지향파라다임에서 큰 역할을 논다. 제품에서의 객체와 현 
실세계에서의 그 대응물사이의 밀접한 대응은 더 좋은 쏘프트웨어를 개발할수 있게 한다. 

객체지향파라다임의 유익성을 또 다른 측면에서 찾아 볼수 있다. 잘 설계된 객체는 
독립적 인 구성단위들이다. 이미 설명된바와 같이 객체는 자료와 그 자료에 대 하여 수행 
되게 되 는 작용들로 구성 되 여 있다. 만일 객체의 자료에 대 하여 수행하게 되 는 모든 작 
용이 그 객체에 포함되면 객체를 개념상 독립적인 실체로 고찰할수 있다. 객체로 모형화 
되는 현실세계의 부분들과 관련되는 제품안의 모든 부분들은 객체 그자체에서 찾아 볼수 
있다. 이와 같은 개념적독립성을 때때로 교갑화라고 부론다 (7.4). 그러나 물 
리 적독립성 이라고 하는 추가적 인 형 태의 독립성 이 존재 한다. 잘 설계된 어떤 객체 에서는 정 
보은페 가 실 현세 부들이 그 객 체밖의 모든것 으로부터 은폐 된 다는것 을 담보하여 준다. 유일 하 
게 허용되는 통신형식은 어떤 특정한 작용을 수행하기 위하여 그 객체에 통보를 보내는것 
이다. 작용이 수행되는 방법은 전적으로 객체 그자체의 책임이다. 이러한 리유로 하여 객체 
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지 향설 계 를 때 때 로 책 임 구동설 계 ( responsibility-driveti des i g 7?)[ Wirfs - Brock , Wilkerson , and 
Wiener , 1990] 또는 계 약에 의 한 설 계 (쇼서 by con / rac /)[ Meyer , 1992 a ] 라고 부론다(책 임 구 
동설계 에 대 한 다른 견해 에 대 하여서는 다음의 《 알고 싶은 문제》를 보시 오.). 


알고 싶© ©지 I 

당신 이 뉴 오를레 안 (New Orleans ) 에 서 살고 있는데 아이 오와 ( Iowa ) 시 에 서 살〕 있는 
작은 어머니의 생일에 선물할 꽃을 마련하려 한다고 하자 [ Budd , 1991]. 방법은 아 >1오와 
시에 있는 모든 화초재배목록을 찾고 그다음 작은어머니집에 가장 가까이에 있4 화초 
재 배 원을 결정 하는것 이 다. 보다 쉬 운 방법 은 1-800- FLOWERS 에 전화를 걸 어 그 조위 에 
꽃선물을 전달할것을 위임하는것이다. 당신은 꽃을 전달할 아이오와시의 화초재 가를 
알 필요가 없다. 

이와 같은 방식으로 어떤 통보가 하나의 객체에 전송될 때 그 요청이 어떻게 수 S 되，： 
가는 전혀 관계가 없을뿐아니라 지어 그 통보문을 보내'# 단위가 그 객체의 내부적 < 구조 
에 대 하여 아■는것을 허 락하지 않는다. 객체 그자체들은 그 통보문을 수행 하는 매 세 - ■를 전 
적 으로 책임 진다. 


구조화파라다임 을 리용하여 개 발한 제 품은 본질에 있어서 하나의 록립적 인 단위 이 다. 
이것은 구조화파라다임이 보다 큰 제품들에 응용될 때 그리 성공적이지 못한 하나의 원 
인으로 된다. 이와 반대 로 객체지향파라다임 이 정 확히 리용되 면 그 결과 개 발된 제품은 여 
러개의 보다 작고 독립성 이 큰 단위들로 구성된다. 객체지향파라다임은 쏘프트웨어제품의 
복잡도를 줄이며 이 로부터 개 발과 유지정 비 가 간단해 진다. 객체지향파라다임의 또 한가지 
긍정적 인 특징은 그것 이 재 리용을 촉진시 킨다는것 이 다. 즉 객체는 독립 적 인 실체 이 기때 문 
에 미래의 제품들에서 리용될수 있다. 객체들에 대한 이러한 재리용은 제8장에서 설명한바 
와 같이 개발과 유지정비에서 시간과 비용을 감소시킨다. 

객체지향파라다임 이 리용되 면 쏘프트웨 어생 명주기(그림 1-1) 는 약간 변경되 여 야 한 
다. 그림 1-7 은 구조화파라다임과 객체지향파라다임 에 대 한 두개의 쏘프트웨 어생명주기 
를 보여 준다. 그 차이 를 명백 히 하기 위하여 우선 구조화파라다임 의 설계 단계를 고찰하 
자. 1.3 에서 서술한바와 같이 이 단계는 두개의 부분적인 단계 즉 구성방식설계와 그다음 
의 상세설계로 나뉘여 진다. 구성방식설계단계에서 제품은 모둘 ( mocMe ) 이라고 부르는 구 
성요소들로 분해된다. 상세설계단계에서 매 모둘의 자료구조와 알고리듬들이 차례로 설 
계된다. 마지막으로 실현단계에서 이러한 모둘들이 실현된다. 

만일 객체지향파라다임 이 대 신 리용된다면 객체지향분석단계의 한 단계는 객체를 
결 정 한것 이 다. 

객체 는 일종의 모둘이 기때 문에 구성 방식설계 는 객체지향분석단계 에서 수행된다. 이 
리하여 객체지향분석은 구조화파라다임의 대응하는 명세작성(분석)단계보다 먼저 진행된 
다. 이것을 그림 1-8 에 보여 준다. 
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1 . 

요구사항확정 단계 

1 . 

요구사항확정 단계 

2. 

명세 작성 (분석)단계 

2\ 

객 체 지 향분석 단계 

3. 

설계단계 

3’. 

객체지향설계 단계 

4. 

실현단계 

4，. 

객 체 지 향프로그람작성 단계 

5. 

통합단계 

5. 

통합단계 

6. 

유지 정 비 단계 

6. 

유지 정 비 단계 

7. 

폐기 

7. 

폐기 


그림 1-7. 구조화파라다임 과 객체지 향파라다임의 생 명주기 의 비 교 

두 파라다임사이 의 이 와 같은 차이 로부터 중요한 결 론을 엄 는다. 구조화파라다 
임 이 리 용될 때 는 거 의 언제 나 분석(명 세작성 )단계 와 설 계 단계사이 에 예 민 한 변 이 
가 존재한다. 결국 명세작성단계 의 목적 은 제 품이 무엇 을 하는가 하는것 을 결정하 
는것 이며 반면에 설계 단계의 목적은 그것을 어떻게 하여 야 하는가를 결정하는것 이 
다. 이와 대조적으로 객체지향분석이 리용될 때는 객체들은 맨 초기부터 생명주기 
에 들어 간다. 분석단계 에서 객체 들이 추출되 며 설계 단계 에서 그것 들이 설계 되 고 
실현단계 에서 코드작성된다. 결국 객 체지향파라다임은 하나로 통합된 방법 이 다. 즉 
단계와 단계사이의 이행은 구조화파라다임에서보다 훨씬 완만하며 이로부터 개발기 
간에 오유의 수는 감소되 게 된다. 


2. 명세작성(분석)단계 

2’. 객체지향분석단계 

• 제품이 무엇을 할것인가를 결정 

• 제품이 무엇을 할것인가를 결정 


• 객체를 추출 

3. 설계단계 

3’. 객체지향설계단계 

• 구성방식설계(모둘을 추출) 

• 상세 설계 

• 상세 설계 


4. 실현단계 

4'. 객체지향프로그람작성단계 

• 적 당한 프로그람작성언어 로 실현 

• 적당한 객체지향프로그람작성언어로 실현 


그림 1-8. 구조화파라다임 과 객체지 향파라다임의 차이 

이미 언급하였지만 하나의 객체를 단순히 자료와 작용들을 모두 교갑화하고 
정 보은페원리 를 실현하는 쏘프트웨어 의 구성 요소로서 정 의하는것 은 불충분하다. 보다 더 
완성된 정의는 제7장에서 주고 있는데 거기에 객체들에 대하여 깊이 있게 서술한다. 
그러 나 우선 이 책 에서 리용한 용어 들을 보다 상세 히 고찰하여 야 한다. 
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1 . 7 .용 어 


이 책 의 거 의 모든 페 지 들에 서 쏘프트웨 어 (새/ mwe ) 라는 단어 가 리용되 고 있 다. 쏘프 
트웨어 는 기 계 가독형 식 의 코드뿐아니 라 매 프로젝 트의 본질 적 인 요소인 모든 문서 들로서 
이루어 진다. 쏘프트웨어는 명세서, 설계문서, 모든 종류의 법적 및 계산문서, 쏘프트웨어 
프로젝 트관리 계 획, 모든 형 태의 안내서 와 같은 관리문서들을 포함하고 있다. 

1970년대부터 프로그람과 체계사이의 차이는 희미해 지게 되였다.《좋은 옛시절 (good 
old days )》 에서 구별은 명백하였 다. 프로그람은 일반적 으로 구멍 이 뚫린 착공카드형 식 의 
실 행할수 있는 자률적 인 코드조각이 였 다. 체계는 련관된 프로그람들의 모임이 였다. 결국 
하나의 체계는 프로그람 P , Q , R , S 로 구성될수 있다. 자기레프 T 1 이 설치되 고 그다음 
프로그람 P 가 실행된다. 자료카드가 읽어 지게 되고 출력레프 T 2, T 3 이 생성된다. 그다음 
레프 T 2 가 다시 감기고 프로그람 Q 가 실행되여 결국 테프 T 4 가 출력된다. 

프로그람 묘는 이 제 레 프 T 3 과 T 4 를 T 5 로 병 합하며 T 5 는 일 련의 보고서 들을 인쇄하 
는 프로그람 S 의 입 력 으로 된다. 

앞단통신처 리기 와 뒤단자료기지관리기 를 가진 콤퓨터상에서 실행 되는 강철공장의 실 
시 간조종을 실 행하는 어 떤 제 품의 정 황들을 비 교하여 보자. 강철 공장을 조종하는 하나의 
토막으로 구성된 쏘프트웨어는 낡은 류형의 체계 에서보다 훨씬 더잘 동작하지 만 프로그 
람과 체계에 대한 고전적인 정의에 따르면 이러한 쏘프트웨어는 의심할바없이 프로그람 
이 다. 체 계(방次 em ) 라는 용어 는 이제 는 하드웨 어 와 쏘프트웨어 의 결 합을 지 적 하기 위해서 
도 리용되고 있다. 실례로 비행기에서 비행조종체계는 비행을 위한 콤퓨터와 거기서 실 
행되는 쏘프트웨어 로 구성되게 된다. 누가 비 행조종체계 라는 용어를 리용하는가에 따라 
서 비행조종체계는 콤퓨터와 그 콤퓨터에 의하여 조종되는 날개와 갈은 부분들에 지령을 
보내 는 위 치 조종장치 와 같은 그러한 조종들도 포함할수 있 다. 

혼란을 피 하기 위하여 이 책 에서는 제품이 라는 용어 를 쏘프트웨어의 중요한 부분을 
의미하는것으로 리용한다. 이러한 약속에는 두가지 원인이 있다. 첫째는 단순히 제품이라 
는 용어 를 리 용함으로써 프로그람과 체 계 사이의 혼란을 없애 는것 이 다. 둘째 리유가 더 
중요하다. 이 책에서는 쏘프트웨어생산공정 ( procaw ) 을 취급하고 있는데 어떤 공정의 마지 
막 결 과를 제 품 ( prac / wc /) 이 라고 부르고 있 다. 쏘프트웨 어 생 산은 두개 의 활동 즉 쏘프트웨 
어 개 발(■지 / hrare developmenf)^ 그에 뒤 따르는 유지 정 비 (■재 ternwce ) 로 이 루어 진다. 결국 
체 계 라는 용어는 현대적 인 의미 로 리용되 고 있다. 즉 하드웨 어 와 쏘프트웨어의 결합，또 
는 조작체 계 와 관리 정 보체 계 와 같은 일 반적 으로 리용되 는 어 휘 로서 리해 되 고 있 다. 

쏘프트웨어 공학에서 널리 리 용되는 단어들중에는 방법론 (me 功 ocfo / ogy ) 과 파라다임 
이라는 단어가 있다. 이 두 단어는 같은 의미 즉 완전한 생명주기를 수행하기 위 
한 기법들의 집합으로서 리용되고 있다. 이러한 리용은 언어를 정확히 리용하는 사람들에 
게 혼란을 가져 온다. 즉 방법론은 방법의 과학을 의미하고 파라다임은 하나의 모형 또는 
패 런을 의 미한다. 쏘프트웨 어 공학자들이 단어 들을 정 확히 리 용할것 을 권고하고 있지 만 불 
구하고 현실적 으로는 너무나 광범히 리 용되 고 있는것 으로하여 이 책 에서는 이 두 단어 를 
모두 기법들의 집합이라는 의미로 리용한다. 

될수륵 피해야 할 하나의 용어는 바그 (6 wg ) 이다(이 단어의 유래에 대하여서는 다음의 
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전 해군소장 그레이스 머레이 포퍼 (Grace Murray Hopper ) 이다. 

1945년 9월 9일 하바드에 서 호퍼 와 그의 동료들이 리용하던 MARK II 를퓨터< 
한 마리 가 날아 들어 와 계 전기 의 접 촉판사이에 끼 워 들었 다. 이 리하여 체 계 에 서 - 
으로 오유가 발생되였다. 호퍼는 오유를 일지에 기록하고《처음으로 바그의 실고 
우가 발견되였다.》라고 썼다. 아직도 부나비가 불어 있는 이 일지는 버지니 아주 
( Dahlgren ) 에 있는 해군지상무기4터에 있는 해군박물관에 전시되여 있다. 

이것이 를퓨터분야에서 처음으로 리용된 바그라는 말일수도 있지만 이 단어- 
에 공학용어 들에 서 리 용되 였 다 [ Shapiro , 1994]. 실례 로 토마스 엘 바 에 디슨은 187 
18일에 다음과 같이 썼다. 

《이 일이 벌어 지고 약간의 고장과 난점들과 같은 바그들이 제기될 때 …》 [Joseph 
1934년판 웨브스타의 신영어사전에서는 바그에 대하여 《장치나 그 조작에서 결힘 
정의하고 있다. 

이것이 호퍼가 그 단어를 리용한 의미와 류사하다는 호퍼의 지적으로부터 
다시 말하여 호퍼 는 자기 가 의 미 하는바를 설 명 한것 이 다. 


오늘날 용어 바그 (6 wg ) 는 오유 ( mw ) 를 단순히 에 둘러 말한것 이 다. 비 록 에두름법 사 
온할 때 일 반적 으로 실제 적 인 손해 는 없 다고 할지 라도 단어 바그는 좋은 쏘프트웨어 사 
게 기 여하지 못할수도 있 다. 특히 어 떤 프로그람작성 자는《 나는 오유를 범 했 다.》라 J 
하지 않고《 바그가 코드에 끼 워 들어 갔다.》고 말할것 이 다. 그러 면 오유에 대 한 책유 
프로그람작성자로부터 바그에 로 옮겨 가게 된 다. 돌림 감기 는 돌림 감기비 루스에 의« 
발생하기때문에 그 누구도 돌림감기에 걸렸다고 하여 프로그람작성자들을 꾸짖지나 
는다. 오유를 바그로 간주하는것은 책 임을 회 피하는 하나의 방법 으로 된다. 이와 반 t 
《 나는 오유를 범했다.》라고 말하는 프로그람작성 자는 자기의 행동에 대 하여 책 임 H 
는 콤퓨터전문가로 된다. 

객체지향에 대한 용어와 관련하여 상당히 혼돈될수 있다. 실례로 어떤 객체의 하나도 
S •구성요소를 위하여 속성 ( a 術切 w / e ) 이 라는 용어외 에도 때때 로 상태 변수(께 /e variable) 코 
용어 가 객체지향과 관련한 문헌들에서 리용되 고 있다. Java 에서는 이 용어 가 실례변 z 
stance van ’ aWe ) 이며 C ++ 에서는 이 용어가 마당으로 쓰인다. 어떤 객체의 작용 i 
관련하여 방법 ( me 功 oc /) 이 라는 용어 가 흔히 리용되는데 그러나 C ++ 에서 이 용어는 사 
함수 (wewfter function) 를 나타낸다. C ++ 에서 어떤 객체의 성 원은 속성(《마당》)이 나 ^ 
을 가리키 고 있 다. Java 에 서 는 용어마당이 속성 (실 례변수)이 나 방법 을 지 적 하기 위하 0 
용된다. 혼돈을 피 하기 위하여 이 책 에서는 될수록 일반적 인 용어속성과 방법을 리나 


그러나 어떤 용어는 널리 리용되고 있다. 실례로 어떤 객체안에서 하나의 




되면 이것을 거의 일반적으로 그 객체에 하나의 통보문을 보낸다고 말한다. 

이 절에서는 이 책에서 리 용되는 여러가지 용어들을 정의 하였다. 이러한 용어들중에 
서 공정 ( procew ) 이라는 용어는 다음장의 주제로 된 다. 

O 야 

-U- 一 I 

쏘프트웨어공학은 주어 진 예산내에서 제때에 사용자들의 요구를 만족시키는 오유 
없는 쏘프트웨어제품을 개발하여 배포하는 학문으로서 정의된다 (1.1). 이 목적을 달성하 
기 위하여 명 세작성 (분석 ), 설 계 (1.4)，유지 정 비 (1.3) 를 비 롯한 쏘프트웨 어개 발의 모든 단 
계들에서 적절한 기 법들을 리용하여 야 한다. 쏘프트웨 어공학은 쏘프트웨 어생명주기의 
모든 단계들을 취급하고 있으며 경제학 (1.2) 과 사회과학 (1.5) 을 비롯하여 여 러 분야의 지 
식 을 포함하고 있다. 1.6 에서 객체 에 대 하여 소개 하고 구조화파라다임 과 객체지향파라다 
임 을 간단히 비 교하였 다. 마지 막부분 (1.7) 에서 이 책 에 리 용된 용어들에 대 하여 설명하 
였 다. 


보 충 

쏘프트웨어공학의 범위에 대한 고전적인 정보원천은 문헌 [ Boehm . 1976] 에 있다. 

문헌 [DeMarco and Lister , 1989] 는 쏘프트웨 어 공학이 실제 적 으로 리 용되 고 있는 범위 
에 대 하여 서 술하고 있 다. 쏘프트웨 어공학이 진정한 공학학문으로 된다고 고찰한 분석 은 
문헌 [ Wasserman , 1996] 과 [ Ebert , Matsubara , Pezze , and Bertelsen , 199 刀에 있다. 

쏘프트웨어공학의 전망에 대하여서는 문헌 [ Lewis , 1996 a , 1996 b ; Leveson , 1997; 
Brereton et al ., 1999; Kroeker et al ” 1999; and Finkelstein , 200 이들에서 서술하였다. 쏘프트 
웨어공학위기의 요인에 대하여서는 IEEE Software 1999년 5월/6월호와 특히 문헌 [ Reel , 
1999] 에서 고찰하였다. 

쏘프트웨어공학의 현재 실천에 대하여서는 문헌 [ Yourdon , 1996] 에서 서술하고 있다. 
쏘프트웨 어공학에서 유지정 비의 중요성 에 대 한 견해 와 그것 을 어떻 게 계 획하겠는가 하는 
것은 문헌 [ Pamas , 1994] 를 참고할수 있다. 쏘프트웨 어 에 대 한 불신임 과 초래되는 위험 
(특히 안전성위험체 계)은 문헌 [Littlewood and Strigini , 1992; Mellor , 1994; and Neumann , 

1995] 에서 서술하였다. 쏘프트웨어의 위기 에 대 한 최근의 견해는 문헌 [ Gibbs , 1994] 와 
[ Glass , 1998] 에 서 주었 다. [ Zvegintzov , 1998] 에 서 는 쏘프트웨 어공학실천에서 얼마만큼 정 
확한 자료들을 실제 로 리용할수 있는가 하는것 을 설명하였 다. 

수학이 쏘프트웨어공학을 안받침해 주고 있다는것은 문헌 [ Pamas , 199이에서 고찰하 
였다. 쏘프트웨 어 공학에 서 경 제 학의 중요성 에 대 하여 서 는 문헌 [ Boehm , 1981] 과 [ Baetjer , 

1996] 에 서 론의하였 다. 

사회과학과 쏘프트웨 어공학에 대한 두개의 고전적 인 저서로는 문헌 [ Weinberg , 1971] 
과 [ Shneiderman , 1980] 을 들수 있다. 책에서는 심리학이나 행동과학에 대한 지식을 요구 
하지는 않는다. 이 문제에 대한 보다 새로운 저서는 문헌 [DeMarco and Lister , 198기이다. 
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브로크의 저서 신화적 인 사람-달 (The Mythical Man - Month )[ Brooks , 1975] 은 쏘프트웨 
어공학의 실현에 대 하여 아주 상세 히 소개하였다. 이 책 에는 이 장에서 언급한 주제들을 
모두 포함하고 있다. 

객체지향파라다임 에 대 한 입 문서적 를은 문헌 [ Budd , 1991] 과 [ Meyer , 199기이 다. 
파라다임 에 대하여 조리 있게 서술한 문헌은 [ Radin , 1996] 이 다. [ Khan , Al - A ' ali , and 
Girgis , 1995] 에서는 고전적인 파라다임과 객체지향파라다임사이의 차이를 설명하고 
있다. 객체지향파라다임 을 리용하여 성 공한 프로젝 트들에 대 하여서 는 문헌 [ Capper , 
Colgate , Hunter and James , 1994] 에서 서술하고 있다. 객체지향파라다임 에 경험 있는 
150여 명 의 쏘프트웨 어개 발자들에 대 한 견해 를 조사한 문헌은 [ Johnson , 200이이 다. 대 
규모적인 객체지향제품을 개발하는데서 배워야 할 학과목교재로서는 [ Maring , 1996] 
과 [Fichman and Kemerer , 199기을 들수 있 다. 문헌 [Scholtz et al ., 1993] 은 객체지 향 
프로그람작성 의 첨 단기 술과 실 천에 대 하여 1993년 4월 에 진행한 토론회보고이 다. 객 
체 지향파라다임 의 최 근 동향에 대 한 여 러 가지 간단한 기 사들은 문 헌 [ El-Rewini et 
al „ 1995] 에서 찾아 볼수 있다. 객체지향파라다임에 대한 중요한 기사들은 IEEE 
Computer 1992년 10월호와 IEEE Software 1993년 1월 호 그리 고 Journal of Systems 
and Software 1993 년 1 월호와 1993 년 11월호에서 볼수 있다. 객체지향파라다임의 잠 
재적인 함정 에 관한 문제는 문헌 [ Webster , 1995] 에서 서술하였다. 

문 제 

1.1. 당신은 수자식 전화기 제 작자들을 위하여 기 본조종체 계 를 개 발할데 대 한 임 무를 
받았다. 개 발예 산은 43만딸라이다. 생 명 주기의 매 단계 에서 얼 마만한 비 용이 들겠는가? 
앞으로 유지정비에는 비용이 얼마나 들겠는가? 

1.2. 당신은 쏘프트웨어공학고문이다. 출판업계의 부지배인이 당신에게 회사의 모 
든 계 산업 무를 수행할수 있 고 여 러 회 사창고안에 서 의 주문품과 재 고품목록과 관련 하여 
본사의 사무원 에 게 정 보를 직 결 식방법 으로 제 공할수 있는 제 품을 개 발해 줄것 을 부탁 
한다. 말단에 서는 15명 의 계 산서기 , 32명 의 주문서기 , 42명 의 창고서기 들이 작업한다. 
18명 의 관리 자들이 자료에 접 근할 필 요가 있 다. 사장은 하드웨 어 와 쏘프트웨어 에 모두 
3만딸라를 지 불하려 고 한다. 그리 고 제 품은 4주동안에 완성할것 을 요구한다. 당신은 그 
에게 무엇이라고 말하겠는가? 고문으로서 그의 요구가 얼마나 리성이 없는가를 생각해 
보시오. 

1.3. 당신은 콜라몬트공화국 해군중장이다. 다음세대 함선대함선미싸일을 위한 조 
종쏘프트웨어를 개 발하기 위하여 어느 한 쏘프트웨 어개 발기 업체를 요청 하기 로 결정 
하였다. 당신은 쏘프트웨어연구개발을 지휘할 책임을 지게 되였다. 콜라몬트정부를 
보위 하기 위 하여 서 는 쏘프트웨 어개 발자들과 계 약하는데서 무슨 조항을 포함시켜 야 
하는가? 
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1.4. 당신은 프로그람기 사이 며 당신의 임 무는 문제 1.3 에서 제 기된 쏘프트웨 어개 발을 
지 휘하는것 이 다. 당신의 회 사가 해 군과 한 계 약을 만족시키 는데 서 실 패할수 있는 정 황들 
을 렬거하시오. 이러한 실패에 대하여 있을수 있는 원인을 분석하시오. 

1.5. 배 포후 15개 월만에 내 연기 관에 서 기 름의 최 량점 성 을 결정하는 기 계 공학 쏘프트웨 
어제품에서 고장이 발견되 였 다. 고장을 퇴 치하는데 18,730딸라가 들었다. 고장의 원인이 
명세서 에는 애매한 문구로 되 여 있다. 명세서작성단계 에서 오유를 퇴 치하는데 대 략 얼마 
만한 비용이 들겠는가? 

1.6. 문제 1.5 에서 제기된 고장이 실현단계 에서 발견되 였다고 하자. 그것을 퇴 치하는 
데 대략 얼마만한 비용이 들겠는가? 

1.7. 당신은 대 규모쏘프트웨어 를 개 발하는 기 관의 책 임 자이 다. 당신은 그림 1-5 를 종 
업원들에 게 보여 주면서 쏘프트웨 어생명주기 에서 신속하게 오유를 찾아 내 라고 재촉한다. 
어 떤 종업 원 이 제 품개 발에 들어 가기 에 앞서 그 누군가가 오유를 제 거하리 라고 기 대하는 
것은 타당치 않은 일이라고 대답했다. 실례로 질문에 제기된 오유가 코드작성에서의 오 
유이라면 설계 단계 에서 그 오유를 어 떻게 퇴 치할수 있는가? 당신은 무엇 이 라고 대 답하겠 
는가? 

1.8. 사전에서 단어 system 을 찾아 보시오. 거기에 몇가지 의미가 있는가? 쏘프트웨어 
공학분야에 적용할수 있는 의미를 찾아 쓰시오. 

1.9. 오늘은 당신이 일을 시작하는 첫날이다. 사장이 당신에게 목록을 보여 주며 
《바그를 찾을수 있는가를 보시오.》라고 말했다. 무엇 이 라고 대 답하겠는가? 

1.10. 당신은 문제 1.1 에서 제시한 제품을 개발할 책임을 지게 되였다. 객체지향 
파라다임 을 리용하겠는가 또는 구조화파라다임 을 리용하겠는가? 대 답과 함께 그 리 
유를 밝히시오. 

1.11. (과정안상 목표) 부록 1에 제시한 브로드렌즈지역 아동병 원제품이 정 확히 실현 
되 였 다고 하자. 이 제 가족면회 ( JCF ) 프로그람은 브로드렌 즈시 의 926 km 반경 내 에 사는 사 
람들만이 아니 라 모든 환자들에 게 적 용된 다고 하자. 현재 쏘프트웨어 제 품을 어 떤 방법으 
로 변화시켜 야 하는가? 처음부터 새 로 시 작하여도 되는가? 

1.12. (쏘프 트웨 어공학독본) 교원은 [ Reel , 1999] 의 복사본을 배 포할것 이 다. 제 품오 
유에 대 한 임의의 표식을 될수록 신속하게 발견할수 있도륵 제품을 어떻게 관리할수 
있는가? 
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제 2 장. 쏘프트웨어개발공정 


쏘프트웨 어 개 발공정은 쏘프트웨 어를 생산하는 과정 이 다. 그것은 쏘프트웨 어 생 명주기 
모형 (1.3) 과 우리 가 리용하게 되 는 도구들(5.4~5上))，쏘프트웨어 를 구성하는데 서 중요한 
개별적인 요소들을 모두 포함하고 있다. 

매 개 개 발기 업 체 들마다 쏘프트웨 어 개 발공정 이 서 로 다르다. 실례 로 문서 작성문제 를 
생각해 보자. 일부 기 업체들은 자체 로 문서를 작성할수 있도록 하는 쏘프트웨어를 연구 
한다. 즉 그러한 제 품은 원천코드를 읽 어 보고 간단히 리해할수 있 다. 그러 나 다른 기 업 
체들은 문서화에 집중한다. 그들은 깐깐하게 명세를 작성하고 그 명세를 방법론적으로 
검 사한다. 그다음 주의 깊게 설계 를 진행하며 코드작업 을 진행 하기전에 설계 를 검 사하고 
또 검 사한다. 그다음 프로그람작성 자들에 게 매 모둘에 대 하여 상세한 설명 을 해 준다. 시 
험실례들은 미 리 계 획되며 매 시 험결과들이 기록되며 시험자료를 주의 깊게 파일로 작성 
한다. 일단 제품이 유지정 비단계 에 들어 가면 모든 임의의 제기된 변경를숄 변경을 진행 
하여 야 할 상세한 리유와 함께 서 면으로 제 출되 여 야 한다. 제 출된 변경 은 오직 주어 진 
권한내 에서 만 진행할수 있으며 문서 가 갱 신되 고 문서 에 대 한 변경 이 승인될 때 까지 는 변 
경이 제품에 통합되지 않는다. 

시험의 강도는 개발기업체들이 비교될수 있는 또 다른 척도로 된다. 일부 기업체 
들이 쏘프트웨어시험에 쏘프트웨어개발예산의 절반까지 소비하는 반면에 다른 기업체 
들은 사용자들만이 제품을 철저 히 시 험할수 있다고 생각하고 있다. 결국 일부 회사들 
은 제 품을 시 험하는데 최 소한의 시 간과 품을 들이고 있으나 사용자들이 제 기하는 문제 
들을 수정하는데는 상당한 시간을 들이고 있다. 유지정비는 많은 쏘프트웨어기업체들 
에서 첫째로 중요한 임무로 되고 있다. 5년, 10년 지어는 20년전에 만든 낡은 쏘프트웨 
어 는 요구가 변화되 는데 따라 계 속 강화되 게 된다. 그리 고 쏘프트웨어 가 여 러해동안 
성공적으로 유지정비되여 온 다음에도 잔류오유들이 계속 나타난다. 거의 모든 기업체 
들은 3~5년마다 한번씩 새 로운 하드웨 어 에 쏘프트웨어 를 넘 겨 준다. 이 것 역 시 유지정 
비 를 구성 하게 된 다. 

이와 대조적으로 아직도 일부 기업체들은 개발은 다른 기업체들에 맡기고 유지정비 
만을 허용하는 연구에 집중하고 있다. 이 방법은 특히 대학의 콤퓨터과학학부들에서 응 
용되고 있는데 여기서는 연구생들이 특정한 설계나 기법이 실현가능하다고 증명하기 위 
한 쏘프트웨어를 구성한다. 공인된 개 념들에 대 한 상업 적 인 리용은 다른 기 업 체들에 맡 
겨 진다(다른 기 업체들에서 쏘프트웨어를 개 발하고 있는 방법 들에 대 해서는 다음의 《 알 
고 싶은 문제》를 보시 오.). 

그러나 정확한 절차를 무시한다고 하여도 쏘프트웨어개발공정은 크게 1.3 에서 서술 
한 7개의 단계 즉 요구사항확정, 명세작성，설계，실현, 통합，유지정 비 와 폐 기를 거 치게 
된다. 이 단계들의 일부는 다른 이 름으로 알려 져 있다. 실례 로 요구사항확정，명세작성 
을 합쳐 서 체 계 분석 ■안 ems 이이 라고 부르기 도 한다. 
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알： 2 싶 e g 제 


왜 쏘프트웨어개 발공정은 기업체마다 완전히 다른가? 그 하나의 리유는 프로그 
1의 기智서 부족하기때문이다. 많은 쏘프트웨어전문가들이 최신기술을 소유하 
있다. 그들은 •그 어떤 다른 방도는 모義거때문에 여전히 Ye Olde Fashioned A 
쏘프트웨어 를 개 발하고 있 다. 

쏘프트웨어개발공정에서 차이가 있게 되는 또 다른 리유는 많은 쏘프트웨어관£ 
노한 관리자로는 되지만 쏘프트웨어개발이나 유지정비에 대하여서는 거의나 알 
‘1•고 있기때문이다. 그들이 이처럼 기술지식이 결여되여 있는것으로 하여 프 J 
경 계 획 에서 심 히 리랄하여 더% 프로젝 트수행 을 계 속해 나갈수 없게 된다. 이것 
는 쏘프트웨 어프로젝트들이 완성되지 못하는 리유로 되고 있다. 

개발공정들사이에서 차이나는 또 다른 리유는 관리에 대한 견해에서의 차이에 
1다. 실례로 어떤 기업체는 제품이 비록 충분히 시험되지 않았다고 하여도 제때 
군것 이 더 좋다고 결정할수 있다. 같은 정황하에서 다른 기 업 체들은 종합적 인 시 
‘1•지 않고 그 제품을 배포하는것이 제품을 철저히 시험한 다음에 배포하는것黑 
큰 위 험 요소들을 포함하고 있 다고 결 론할수도 있 다. 요점 은 쏘프트웨어 가 인 간에 
논되고 해 당한 기 업체 에서 진행하는 개발공정 이 그 기 업체에서 일하는 개 별적 인 
관련된다는것이다. 만일 그러한 개별적인 사람들이 의리가 있고 근면하고 지적이 
늘을 소유하고 있다면 그 기 업체 에서 진행하는 쏘프트웨 어개 발공정은 만족스럽게 
1다. 유감스럽게도 그 반대의 경우도 있을수 있다. 


l 기 어 떤 단계 들은 부분적 으로 나누어 진행 될수 있다. 실례 로 설계단 
구성방식 설계 (아 cfe 시’ gn ) 와 상세 설계 ( c / eto ’/ ec / design) 로~ 분할 J 
한 단계들에서 시험단계는 따로 떨어 져 있지 않다. 이것이 빠져 있는 
려한것이다. 시험은 따로 떨어 진 단계가 아니라 쏘프트웨어생산의 모 
행되는 사업이다. 요구사항도 시험되여야 하고 명세서도 시험되여야 하 
I 야 하는 등 시험 이 진행되 여 야 한다. 개 발공정 에서는 다른 사업을 거 
I 시험을 진행하여 야 할 때 가 있다. 이것은 매 단계의 마감(검증)에서 
품이 의뢰자들에게 넘어 가기전에 진행되여야 한다(확인). 비록 시험이 
는 있어도 시험 이 진행되지 않는 때 란 절대로 있을수 없다. 만일 시험。 
보는 단계로 취급된다면 제품개발과 유지정비과정을 비롯한 매 단계들 
진행되지 않는것으로 하여 실제적인 위험이 조성되게 된다. 또한 문서 
진 단계가 아니다. 그것은 바로 다음단계를 시작하기전에 매 단계를 
뉴 하기때문이다. 

어떤 제품을 제때에 배포하여야 한다는것은 바로 문서작성을 뒤로 ^ 
제 품을 절 대 로 완성 할수 없 다는것 이 다. 

쏘프트웨어개발공정의 어떤 초기단계에 책임이 있는 개별적사람은 문 






로운 정보를 고려하여 실현단계에서 수정되여야 한다. 설계가 설계림에 의하여 
완전히 문서화되지 못하면 그것에 대한 수정은 아주 어렵게 된다. 

4. 원래의 설계자들은 설계가 수정된 다음 그것을 문서화하기 어렵게 된다. 

이 런 리 유로 하여 쏘프트웨 어개 발공정 의 매 단계 를 위한 문서 는 다음단계 를 시 작하 
기전에 그 단계에 책임이 있는 림이 완성하여야 한다. 더우기 문서는 제품의 현재 판본 
을 반영하도록 계속 갱 신하여 야 한다. 이 장에서는 제 품이 걸쳐 야 할 단계들을 서술하고 
그와 함께 매 단계에서 제기될수 있는 가능한 난점들에 대하여 서술한다. 이밖에 매 단 
계 에 적 합한 시 험절차도 서 술한다. 쏘프트웨 어생산과 관련된 난점들을 해 결하는것은 일 
반적으로 중요하다. 그리고 이 책의 나머지 부분들에서는 적당한 기법들에 대하여 서술 
하고 있다. 이 장의 첫부분에서 다만 난점들을 강조하였지만 독자들은 그 해결과 관련된 
절들이나 장들을 안내 받게 된다. 따라서 이 부분에서는 쏘프트웨어개발공정에 대한 개 
괄뿐아니 라 이 책의 나머지 부분들에 대한 안내를 많이 주고 있다. 

매개 단계들과 관련된 문제들에 대하여 이러한 설명을 한 다음 쏘프트웨어생산에서 
제기되는 고유한 난점들을 전반적으로 서술하였다. 이 장은 쏘프트웨어개발공정을 개선 
하기 위한 국내 및 국제 적발전추세 에 대 한 론의 로 결 속된 다. 

2.1. 의릐자, 개발자, 사용자 

여기서는 몇가지 예비적인 정의가 필요하다. 의뢰자 ( c // e 때는 어떤 제품을 개발해 줄 
것 을 요구하는 개 별적사람 또는 기 업체 이 다. 개 발자 ( cfeve / oper ) 는 그러 한 제 품개 발에 책 임 
이 있는 기 업체의 성 원이 다. 개 발자는 요구사항확정단계 로부터 시 작하여 개 발공정의 모 
든 측면에 대하여 책임을 지거나 또는 임의의 설계된 제품의 실현에 대하여서만 책임을 
질수 있 다. 용어 쏘프트웨 어 개 발 Oo/ftvare c / eve / o 夕은 제 품이 유지 정 비 단계 에 들어 가 
기 전 쏘프트웨 어생 산의 모든 측면을 포함한다. 명세작성 과 계 획 작성, 설계 , 시 험 또는 문 
서작성 을 비 롯한 쏘프트웨어 의 부분품을 개 발해 나가는 매 단계 의 과제 들은 쏘프트웨 어 
개 발들로 구성 되 여 있 다. 쏘프트웨어 는 개 발된 다음 유지 정 비 되 여 야 한다. 

의뢰자와 개발자는 다 같은 기업체에 속할수 있다. 실례로 의뢰자는 보험회사의 서기 
일수도 있고 개발자는 그 보험회사의 관리정보체계를 맡아 보는 부사장소속의 한 성원일 
수도 있다. 이것을 내부쏘프트웨어(油 em ?/ 새/ mwe ) 개발이라고 부론다. 다른 한편 계약식 
쏘프트웨어 ( co «/ rac / 가 있는데 이때 의뢰자와 개발자는 완전히 독립적인 기업체 

들로 된다. 실례로 의뢰자는 방위성의 장관일수도 있고 개발자들은 무기체계용쏘프트웨 
어를 전문으로 하는 주요방위쏘프트웨 어계 약자들일수 있다. 훨씬 더 작은 규모에서 말하 
면 의 뢰 자는 한사람이 진행하는 업 무에 서 의 부기 원일 수 있 으며 개 발자는 시 간제 로임 으로 
쏘프트웨어를 개 발해 주고 수입 을 얻는 대 학생 일수도 있다. 

쏘프트웨 어 생 산에 참가하는 세번째 대 상은 사용자이 다. 사용자는 의 뢰 자들이 제 품을 
주문하는데 리해 관계 를 가지 면서 그 쏘프트웨어 를 리용할 사람들이 다. 보험 회 사의 실 례 
에 서 사용자는 쏘프트웨어 를 리용하여 가장 적 합한 방안을 선택해 나가는 보험대 리 인# 
이 다. 일 부 실 례 들에 서 는 의 뢰 자이자 사용자로 될 수 있 다(실 례 로 앞에 서 이 야기한 부기 
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원을 들수 있다.). 

한명의 의뢰자를 위하여 만들어 진 값 비싼 쏘프트웨어와는 반대로 문서처리기나 표 
처 리프로그람과 갈은 쏘프트웨 어들은 여 러개 복사되 여 수많은 구매자들에 게 눅은 가격 으 
로 팔리게 된다. 이러한 쏘프트웨어제작자(마이크로쏘프트회사나 볼랜드회사와 같은)들은 
대량판매로 제품을 개발하는데 드는 가격을 보상하고 있다. 이러한 류형의 쏘프트웨어는 
보통 상업용기성 (cowmer/ca/ off - the - shelf ， COTS) 쏘프트웨 어라고 부론다. 이러한 쏘프트웨 
어 에 대 한 초기의 학술용어는 수축포장쏘프트웨 어 소- wra/pec/ sq/hvare) 였는데 그것은 

CD 나 디스케 트, 설명서 그리 고 사용허 가신청서 등을 포함한 통들이 거의나 수축포장되 
기때 문이 다. 요즘 COTS 쏘프트웨어는 흔히 WWW 에서 내 리적재되 고 있으며 수출포장통 
송 없어 졌다. 이런 리유로 하여 COTS 쏘프트웨어는 최근에 때때로 클리크포장쏘프트웨 
( dick-wrapped sq/hvare) 라고 부르고 있다. COTS 쏘프트웨 어는《 시장》을 대상하여 개 
발된 다. 즉 쏘프트웨어 가 개 발되 여 사서 쓸수 있게 될 때 까지 는 특정한 의 뢰 자나 사용자 
가 없게 된다. 우리는 이 장의 다음부분에서 쏘프트웨어생명주기의 7개 단계에 대하여 
서 술하며 매 단계 를 시 험하여 그 역 할을 주의 깊 게 분석한다. 첫 단계 는 요구사항확정단 
계 이 다. 


2. 2. 요구사항확정단계 

쏘프트웨어개발은 품이 드는 공정이다. 개발공정은 보통 의뢰자의 견해에 따라 기업 
의 리득이라든가 또는 그 어떤것이 경제적으로 정당화될수 있는 쏘프트웨어제품에 주목 
하여 의뢰자들이 개발기업체들에 의뢰하게 될 때 시작되게 된다. 개발공정의 임의의 단 
계에서 의뢰자들이 쏘프트웨어가 비용상 효률적이라는것을 믿지 못할 때는 개발은 즉시 
에 정지되고 만다. 이 장에서는 의뢰자들이 비용이 타당하다고 간주한다는것을 념두에 
둔다(사실상《비용》은 언제나 순수한 재정상의 문제로 되는것이 아니다. 실례로 군사 
분야의 쏘프트웨어는 흔히 전략적인 또는 전술적인 목적으로 만들어 진다. 여기서 쏘프 
트웨어의 비용은 바로 개발되고 있는 무기가 없는것으로 하여 받게 되는 잠재적인 위험 
으로 된다.). 의뢰 자가 개발자와 처음 만나면 의뢰 자는 제품을 개 념화하여 륜곽적으로 설 
명한다. 개발자의 견지에서는 요구하는 제품에 대한 의뢰자의 설명이 명백치 않거나 불 
합리하며 모순적 이고 단순히 실현불가능할수도 있다. 이 단계에서 개발자들의 과제는 의 
뢰자가 무엇을 요구하고 어떤 제약이 있는가를 의뢰자로부터 정확히 밝혀 내는것이다. 
전형적인 제약은 제품을 완료하는 마감기한이다. 실례로 의뢰자는 완전한 제품이 14개월 
안으로 완성 되 여 야 한다고 규정할수 있 다. 기 타 여 러 가지 제 약들은 흔히 신뢰 성 (제 품은 
99%에 해당한 시간동안 가동하여야 한다.)이나 객체의 크기(그것은 의뢰자의 콤퓨터상에 
서 동작하여야 한다.)로 나타낼수 있다. 

일반적으로 가장 중요한 제한은 비용이다. 그러나 의뢰자는 제품을 개발하는데 얼마 
만한 비용이 드는가를 개발자에게 좀처럼 말해 주지 않는다. 그대신에 일반적으로 일단 
명 세작성 이 끝나면 의 뢰 자는 개 발자들에 게 프로젝 트를 완성 하기 위한 가격 을 물어 본다. 
의뢰자는 개발자들이 부른 비용이 자기들이 그 프로젝트에 대하여 세운 예산량보다 더 
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적을것이라는 기대를 가지고 이러한 값부르기절차에로 넘어 간다. 의뢰자들의 요구에 
따라 진 행 하는 이 런 초보적 인 조사를 흔히 개 념 탐구 ( co « ce ，/ ex /»/ oraft ’ o «) 라고 한다. 개 발 
림과 의뢰자림성원들이 계속 만나는 과정에 제기된 제품의 기능이 성과적으로 완성되고 
기 술적 인 실 현 가능성 과 재 정 상의 타당성 이 분석 된 다. 

지 금까지 는 모든것 이 단순한것 같다. 유감스럽 게 도 요구사항확정단계 는 흔히 부적 당 
하게 수행된다. 제품이 최종적으로 사용자들에게 배포되면 아마 의뢰자는 명세서에 수표 
한 다음 1년 또는 2년후에 개 발자들에게 《 내 알기 에는 이것 이 내 가 요청한것 이지 만 사 
실은 그것 이 내 가 바라던것 용 아니 다.》라고 말할수 있 다. 결 국 의 뢰 자들이 요청 하였 고 
따라서 개 발자들이 의 뢰 자가 바라던것 이 라고 생 각한것 은 의 뢰 자들이 사실상 요구한것 이 
아니 였 다. 이 런 상태 에 처하게 된 데 는 여 러 가지 리유가 있 을수 있 다. 우선 의 뢰 자들은 자 
기의 기 업체 들에서 진행 하고 있는것 을 사실상 리해하지 못하고 있을수 있다. 실례 로 현 
재 일감처 리 가 느리 게 진행 되 는 원 인이 자료기 지 가 잘못 설계되 였기때 문이 라면 쏘프트웨 
어개 발자들에 게 보다 빠른 조작체 계 를 요청할 필 요는 없 다. 또는 의 뢰 자가 수지 가 맞지 
않는 련쇄 소매창고를 관리 한다고 하면 판매 와 로임 , 지 불계 산, 수입 계 산 등과 갈은 항목 
들을 반영하는 재정 경 영정 보체 계 를 요청할수 있다. 만일 손실을 보는 실제적 인 원인이 
감소(상점 에서 의 좀도적 과 종업 원들에 의한 절 취)에 있 다면 그런 제 품은 리용가치 가 거 
의나 없다. 이런 경우라면 재정관리제품이 아니라 창고관리제품이 요구된다. 

그러 나 의 뢰 자들이 흔히 제 품을 잘못 요청하게 되 는 기 본원 인은 쏘프트웨어 가 복잡 
하기 때 문이 다. 만일 쏘프트웨어 전문가가 쏘프트웨어 의 일부분과 그 기 능을 시 각화하기 가 
곤난하다면 거의나 콤퓨터 에 대 하여 파악이 없는 의뢰 자에 게 있어서 문제는 더 악화될것 
이 다. 이 에 대 처 하기 위한 여 러 가지 방법 들이 있는데 그중의 하나가 신속원형작성 이다. 

신속원형 ( ra ; 治/ /次 pe ) 은 서둘러 모아 놓은 프로그람의 부분인데 그것은 목표제품 
의 대부분의 기능들은 병합하고 있지만 파일갱신이나 오유조종과 같은 의뢰자들에게 보 
통 보이지 않는 측면들은 빠뜨려 놓고 있다. 그러면 의뢰자와 사용자는 그것이 자기들의 
요구에 부합되는가를 결정 하기 위하여 원형을 가지 고 실험을 진행한다. 신속원형 은 의뢰 
자와 사용자들이 자기들의 요구하는 기능을 교갑화한다는것을 확인할 때까지 변화될수 
있다. 신속원형작성과 기 타 다른 요구사항분석기 법은 제10장에서 상세히 론의된다. 

2. 2. 1. 요구사항확정단계에서의 시험 

매 쏘프트웨어개발기업체들에는 배포된 제품이 의뢰자들이 주문한것이고 제품이 모 
든 면에서 정확이 개발되였다는것을 담보하는것을 책임지는 그롭이 있어야 한다. 이러한 
그를을 쏘프트웨 어품질 보증 quality assurance ; SQA ) 그를이 라고 부론다. 쏘프트웨 
어의 품질은 쏘프트웨어의 명세서 에 반영된 범위내 에서 담보된다. 품질과 쏘프트웨 어품 
질보증에 대 해서는 6장에서 자세 히 서 술되는데 SQA 는 표준을 설정 하고 집 행하는 역 할을 
수행 한다. 

SQA 그룹은 개 발공정 의 시 작부터 역 할을 옳바로 수행하여 야 한다. 특히 제 품이 의 뢰 
자들의 요구를 만족시키는것은 사활적인 문제이다. 따라서 SQA 그룹은 신속원형에 대한 
마지막 판본이 전적으로 만족한다는것을 의뢰자와 함께 확증하여야 한다. 
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제품이 자기들의 요구를 반영하고 있다는것을 확증하도록 의뢰자와 사용자가 다같이 
주의 깊게 신속원형을 검사하는것이 중요하다. 아무리 세심하게 검사가 진행된다 하더라 
도 제품이 개발되고 있는 동안 개발림을 조종하는 세력이 요구사항의 변화를 요구할 가 
능성이 항상 존재한다. 더우기 부분적으로 완성된 제품에 대하여 필요한 변경이 진행될 
때까지는 개발이 유지되여야 한다. 

쏘프트웨어개발에서 기본문제는 이른바 목표가 이동하는 문제이다. 즉 개발기간 의 
뢰자의 요구사항이 변화되는것이다. 이렇게 되는 리유의 하나는 주위환경에서 뜻하지 않 
은 우연적인 변화가 일어 난다는데 있다. 실례로 어떤 회사가 자기 사업을 확장하거나 
또는 다른 회사에 채용된다면 그때는 여전히 개발상태에 있는 제품들을 포함하여 많은 
제품들을 변경하여야 한다. 그러나 이동하는 목표문제의 기본원인은 자기들의 요구를 바 
꾸는 의 뢰 자들에 게 있다. 16.4.4 에서 설명한바와 같이 의 뢰 자가 충분한 권한을 가지 고 있 
다면 어찌할 도리 가 없다. 

2. 2. 2. 요구사항확정단계에서의 문서작성 

요구사항확정단계에서 만들어 진 문서는 일반적으로 신속원형과 구성변경된 신속원 
형이 기초하고 있는 의뢰자와 사용자들의 론의에 대한 기록을 포함하고 있다. 만일 림 이 
신속원형을 만들지 않기로 결심하였다면 의뢰자의 요구를 서술하는 요구문서가 작성되게 
된다. 이 문서는 의뢰자와 선택된 사용자들, 개발림에 의하여 SQA 그룹이 그것을 면밀히 
조사하기전에 검열되여야 한다. 


2. 3. 명세작성단계 

일단 의뢰자가 개발자들이 요구사항을 리해하였다는것을 인정하면 명세서 ( spec 與 carton 
document ) 는 명 세 작성 림 에 의 하여 작성 된 다. 비 형 식 적 요구사항확정 단계 와는 반대 로 명 세 
서는 그 제품의 기능 즉 정확히는 그 제품이 무엇을 하기로 되여 있는가를 명백히 서술 
하고 있으며 그 제품이 만족해야 할 제약들을 렬거하고 있다. 명세서는 제품에 대한 입 
력과 요구되는 출력을 포함한다. 실례로 의뢰자가 로임지불제품을 필요로 한다면 그때 
입력에는 세금이 정확히 계산될수 있도록 개인자료철로부터 얻을수 있는 정보는 물론 매 
종업 원들의 지 불량과 로동시 간에 대 한 자료를 포함된 다. 출력 은 로임 지 불행표와 보고서 
이 다. 이 밖에 명세서는 의 료보험비 나 동맹비 그리 고 년료보장비 와 같은 넓 은 범위의 공 
제액을 정 확히 관리할수 있는 조항들을 포함한다. 

제 품의 명세 서 는 하나의 제 약을 구성한다. 쏘프트웨 어개 발자들은 명세 서 의 접 수기 준 
을 만족시키 는 제 품을 배 포할 때 계 약을 완수하였 다고 생 각한다. 이 런 리유로 하여 명 세 
서 에 는 적 합한 CswtoWe )， 편 리 한 ( convem ’ en /)， 풍부한 ( ampfe ) 또는 충분한 ( e « owgA ) 과 같은 정 
확치 못한 용어들이 나 최 량적 인 ( o 夕 //■/) 또는 98% 완전한(98% percent complete ) 파 같이 
정 확하지 만 실천적 으로는 부정 확한 용어 들을 포함하지 말아야 한다. 쏘프트웨 어 개 발계 약 
은 소송에 제기될수 있는 반면에 의뢰자와 개발자들이 같은 기업체에 있을 때에는 명세 
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서가 법률상의 사업의 기초로 될 경우는 없게 된다. 그러나 내부쏘프트웨어개발의 경우 
에조차 명세서는 언제나 그것이 재판의 증거로 리용되는것처럼 작성되여야 한다. 보다 
중요한것은 명세서 가 시험과 유지정 비 에서 모두 중요하다는것 이 다. 

명세서가 정확하지 않는 한 명세의 정확성여부를 결정할수 없으며 하물며 실현이 명 
세서를 만족시키는가 못시키는가를 결정할수 없다. 만일 명세들을 정확히 서술한 문서가 
없으면 유지정비단계에서 명세서를 변경시키는것이 어렵게 된다. 

명세작성단계에서 여러가지 난점들미 제기될수 있다. 명세작성림에 의하여 제기될수 
있는 오유의 하나는 명세서가 애매하다는것 즉 어떤 문장이나 부분들이 하나이상의 타당 
한 해석을 가지고 있다는것이다. 다음의 명세서를 고찰해 보자. 

《 하나의 부분기록과 하나의 식물기록이 자료기지로부터 읽 어 진다. 만일 그것 이 문 
자 A 에 직 접 뒤따르는 문자 Q 를 포함하고 있 다면 그때 에 그 부분기 록을 그 식 물기 록에 
로 옮기는데 드는 비용을 계산하시오.》 

우의 문장에서 그것이 무엇으로 간주되는가 즉 부분기록인가 아니면 식물기록인가? 
사실 상 그것 은 아마도 자료기 지 를 의 미할수 있 다. 

명세서는 또한 불완전할수도 있다. 즉 일부 련관된 사실이나 요구사항들을 빠뜨릴수 
도 있다. 실례로 명세서는 입력자료가 오유를 포함하게 되면 무슨 작용이 일어 나겠는가 
를 서 술하지 않을수도 있다. 더 우기 명세서 에는 모순도 있을수 있 다. 실례 로 발효과정 을 
조종하는 제 품에 대 한 명세서 의 한 곳에는 압력 이 35 psi 을 넘 으면 발브 M 17 이 닫겨 져 야 
한다는것을 서술하고 있다. 또 다른 곳에는 압력 이 35 psi 을 넘 으면 그때에는 조작기 에 즉 
시 경고신호를 보내야 한다고 서술하고 있다. 즉 조작기가 30 s 이내에 보수되지 않으면 
발브 M 17 은 자동적으로 닫겨 져야 한다는 경고가 서술되고 있다. 명세서에서의 이러한 
문제 들 이 정 정 되 지 않는한 쏘프트웨 어 개 발공정 은 진행 될 수 없 다. 

일 단 명세서 가 완성 되 면 세 부계 획작성 과 타산이 시 작된다. 프로젝 트를 개 발완성하는 
데 기간이 얼마나 걸리고 비용이 얼마나 드는가 하는것을 미리 알지 못하고서는 그 어떤 
의 뢰 자도 쏘프트웨 어프로젝 트를 허 가하지 않을것 이 다. 개 발자들의 견지 에 서 이 두 항목 
은 아주 중요하다. 만일 개발자들이 프로젝트의 가격을 낮게 정한다면 의뢰자들은 합의 
한 가격 으로 지 불하게 되 는데 그 가격 은 개 발자들에 게 있어 서 실제 가격보다 훨씬 더 적 
은 값일수 있다. 반대로 개발자들이 프로젝트의 가격을 높이 정한다면 의뢰자들은 그 프 
로젝 트를 포기하거 나 또는 값을 보다 적 당하게 결정하는 다른 개 발자들에 게 그 일 감을 
맡기게 된다. 만일 개 발자들이 프로젝 트를 완성하는데 걸 리는 시 간을 과소평 가한다면 제 
품을 늦게 배포하는것으로 하여 의뢰자들의 신용을 잃게 된다. 최악의 경우에는 계약에 
따라 지연에 대한 벌금이 부과되여 개발자들은 재정상 곤경을 겪게 된다. 또한 개발자들 
이 배포될 제품을 개발하는데 걸리는 시간을 과대평가한다면 의뢰자들은 보다 빨리 제품 
을 배달할것을 약속하는 다른 개발자들에게 일감을 맡기게 될것이다. 개발자들이 개발기 
간과 전체 가격을 타산하는것은 충분하지 않다. 개발자들은 적당한 사람들에게 개발공정 
의 여 러단계 를 맡겨 주어 야 한다. 실례 로 코드작성 림 은 설계문서 가 SQA 그룹에 의하여 
인정되기전에는 코드작성을 시작 할수 없으며 명세작성림이 자기 과제를 완성하기전에는 
설계림이 필요 없게 된다. 달리 말하면 개발자들은 앞서나가면서 계획을 작성하게 된다. 
쏘프트웨 어프로젝 트관리 계 획 ( SPMP ) 은 개 발공정 의 개 별적 인 단계 를 반영하며 매 과제 를 
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완성하기 위한 최종기간은 물론 매 개발기업체안의 누가 매 과제에 포함되는가를 보여 
주도록 작성되여야 한다. 

이런 구체적인 계획이 작성될수 있는 가장 이론 시기는 명세서가 완성되는 때이다. 
그전에는 프로젝트가 너무나도 막연하여 완성된 계획작성에 착수할수 없다. 프로젝트의 
어떤 측면은 반드시 시작부터 잘 계획되여야 하지만 개발자들이 무엇이 개발되는가를 정 
확히 알 때까지는 그것을 개발하기 위한 계획의 모든 측면을 명시할수는 없다. 

따라서 일단 명세서가 완성되여 검열되면 쏘프트웨어프로젝트관리계획의 준비가 시 
작된다. 계획의 기본구성부분은 배포물(의뢰자들이 얻으러 하는것), 리정표(의뢰자들이 언 
제 얻는가)와 예산안(비용이 얼마나 드는가)으로 된다. 

계획은 아주 상세하게 쏘프트웨어개발공정을 서술한다. 그것은 리용되여야 할 생명주 
기모형이나 개발기업체의 조직구성, 프로젝트의 책임성，경영목적과 우선권，리용되게 될 
기법과 CASE 도구, 세부일정계획, 예산안，자원할당과 같은 측면들을 포함한다. 전반적인 
계획의 기초로 되는것은 개발기간과 비용에 대한 타산이 다. 이 러한 타산을 내릴수 있는 기 
법은 9.2 에서 서술하고 있다. 명세 작성단계는 11장과 12장에서 서술하고 있다. 즉 고전적 인 
기 법은 11장에서, 객체지향분석은 12장의 주제 이 다(용어 분석 신비은 때때 로 명세작성 
단계 에서 의 행동을 나타내 는데 리용되 며 따라서 적체지향분석 ( ofty ’ ec / 단계 

에서 리용된다.). 


2. 3. 1 . 명세작성단계에서의 시험 

1장에서 언급한바와 같이 배포된 쏘프트웨어에서 생기는 오유의 기본원천은 쏘프트 
웨어가 의뢰자의 콤퓨터에 설치되여 의도하는 목적으로 의뢰자들의 기업체에서 리용될 
때 까지 발견되 지 않는 명세 서 에서 의 오유들이다. 따라서 SQA 그룹은 명세서 를 주의 깊게 
살피면서 모순이 있는것，애매한것 그리 고 불완전한 기 호들을 찾아 보아야 한다. 이 밖에 
SQA 그룹은 명세서 가 실현가능하다는것을 담보해 야 한다. 실례 로 어떤 특정한 하드웨 어 
구성요소가 충분히 빠르다는것 또한 의뢰자의 현재 직결디스크측정용량이 새로운 제품을 
관리하는데 충분하다는것 등을 담보해 야 한다. 만일 어 떤 명세서 가 시 험 가능하다면 그것 
이 가져 야 할 속성 의 하나는 추적 가능성 (/ raceaW / 均0이 다. 추적 가능성 이 란 요구사항확정 단 
계에서 의뢰자림이 작성한 설명문들로부터 명세서에 있는 매 설명문들을 추적할수 있어 
야 한다는것 이 다. 만일 요구사항이 방법론적으로 서술되고 정확히 번호화되여 있고 교차 
참조하도록 되 여 있으며 첨수화되 였 다면 SQA 그룹이 명세서 를 추적하여 그것 이 실지 로 
의뢰 자의 요구를 반영 하고 있다는것 을 담보하는것 이 거의나 어 렵지 않다. 만일 신속원형 
작성 이 요구사항확정단계 에 서 리용되 면 련관된 명세 서 의 설명 문들은 신속원형 에 대 하여 
추적할수 있 어 야 한다. 

명세서를 검열하는 가장 좋은 방법은 심사이다. 명세작성림과 의뢰자림의 대표자들 
이 참가한다. 면담은 보통 SQA 그룹성 원들에 의하여 집 행 된다. 심 사의 목적 은 명세 서 가 
정 확한가를 결정하는것 이 다. 심 사성 원들은 명세서 를 검 열하면서 문서 에 대 하여 오해 가 
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없다는것을 담보하게 된다. 관통심사회의와 검 토는 두가지 류형의 심사로 되는데 그에 
대하여서는 6.2 에서 서술한다. 일단 의뢰자가 명세서에 수표하였을 때 진행되는 세부계획 
작성과 타산에 대 한 검 열을 생각해 보자. SPMP 의 매 측면들이 SQA 그룹에 의하여 깐깐 
히 조사된다는것 이 필수적 인 반면에 계 획의 기 한과 가격타산에 특별한 주의를 돌려야 한 
다. 이를 위한 한가지 방법 은 관리 자측이 계 획 작성단계의 초기 에 개 발기 한과 비 용이 2개 
(또는 2이상) 독립 적 인 타산을 얻 고 그다음 중요한 차이를 일 치시키는것 이 다. SPMP 와 관 
련하여 그것을 증명 하기 위한 가장 좋은 방법은 명세서의 심 사와 류사한 심 사를 진행하 
는것 이 다. 개 발기 한과 가격타산이 만족하면 의 뢰 자는 프로젝 트의 개 발을 허 용한다. 

2. 3. 2. 명세작성단계에서의 문서작성 

명세작성단계 는 두개의 기 본결과를 내보낸다. 첫째 는 명세서 이다. 11장과 12장에서는 
어떻게 명세서 가 작성되 는가를 서술하고 있다. 두번째는 쏘프 트웨 어 프로젝트 관리계획 이 
다. SPMP 를 설 계하는 방법 에 대 하여 9.3 부터 9.5 까지 에 서 주고 있 다. 다음단계 는 제 품을 
설 계 하는것 이 다. 


2. 4. 설계단계 

제품의 명세서는 그 제품이 무엇을 하는가를 알려 준다. 설계단계의 목적은 제품이 
그것을 어떻게 수행 하는가 하는것 을 결정 하는것 이 다. 명세 작성을 시 작하면서 설계 림은 
제품의 내부적인 구조를 결정한다. 설계자들은 제품을 모둘 즉 제품의 나머지부분들에 
대한 대면부가 잘 정의되여 있는 독립적인 코드의 부분들로 분해한다(객체는 모둘에 대 
한 특정한 류형으로 된다.). 매 모둘의 대면부 즉 모둘에 들어 오는 인수들과 모둘로부터 
귀환되는 인수들은 상세히 서술되여야 한다. 실례로 어떤 모둘은 핵반응기에서 물의 준 
위를 측정하며 준위가 너무 낮으면 소리를 내여 경고를 울리게 한다. 군용비행기제품의 
객체에 있는 방법은 둘 또는 그이상의 날아 오는 적미싸일의 자리표모임을 입력으로 취 
하고 그것의 탄도를 계산하며 조종사에게 가능한 회피동작을 알려 주기 위하여 또 다른 
객체에 통보문을 보내줄수 있다. 

일 단 개 발림 이 모둘분해(구성 방식 설계 ; architec t ural design ) 를 완성 하면 상세 설계 
(detailed design ) 가 진행된다. 매 모둘에 대하여 알고리듬이 선택되고 자료구조가 선택된 
다. 모둘분해 가 진행되 는 동안 설계 림은 채 택되는 설계결정 에 대 하여 하나의 기록으로 
주의 깊게 보존해 야 한다. 이 정 보는 두가지 리유로 하여 중요하다. 첫째 로 제 품이 설계 
되는 동안에 설계 림 이 궁지 에 빠져 어 떤 부분에 되돌아 와 다시 설계를 진행하여 야 할 
때 가 있다. 특정한 결정 이 채택된 원인을 기록하면 이 러한 정황이 발생 하였을 때 개발림 
이 그것 을 되 돌아 추적해 나가는데 서 도움이 된다. 

설계결정들을 유지해야 할 두번째 리유는 유지정비와 관련되여 있다. 리론적으로 제 
품설계는 설계전반에 영향을 주지 않으면서 새로운 모둘을 추가하거나 현존 모둘을 교체 
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하여 앞으로 확장될수 있도록 개방적이여야 한다. 물론 실천적으로 이러한 리상을 실현 
하기 어렵다. 현실세계에서의 최종기한에 대한 제약은 이후의 설계가들이 확장에 대해서 
는 생각하지 않고 원래의 명세서를 만족시키는 설계를 최대한 빨리 완성하기 위하여 노 
력하도록 한다. 이후의 확장(제품이 의뢰자들에게 배포된후에 보충하게 되는)이 명세서에 
포함되여 있으면 이것들이 설계에서 고려되여야 하는데 이런 경우는 극히 드물다. 일반 
적으로 명세서는 이로부터 설계는 현존 요구사항만을 취급한다. 이밖에 제품이 여전히 
설계단계에 머물러 있는 동안은 가능한 모든 이후의 확장에 대하여 결정할수는 없다. 마 
지막으로 설계에서 모든 이후의 가능성을 고려하여야 한다면 결국은 취급하기 힘들게 되 
며 최악의 경우에는 너무 복잡해서 실현이 불가능하게 된다. 그래서 설계가들은 제품전 
체를 다시 설계하지 않고 여러가지 합리적인 방법으로 확장될수 있는 설계를 제기하여야 
한다. 그러나 주요한 확장을 거치는 제품에서 그 설계가 이후의 변화를 간단히 다룰수 
없는 때도 있다. 이러한 단계에 이르면 제품은 전체적으로 다시 설계되여야 한다. 원래의 
모든 설계결정들에 대한 근거를 보관한 기록을 리용하여 재설계림은 보다 쉽게 일할수 
있 다. 


2. 4. 1 . 설계단계에서의 시험 

2.3.1 에 서 언급한바와 같이 시 험가능성 에 서 가장 중요한 측면은 추적가능성 (/ raceaW / 切) 
이다. 설계의 경우에 이것은 설계의 매 부분이 명세서에 있는 설명문과 련관되여 있다는 
것을 의미한다. 적 당하게 교차참조되는 설계는 SQA 그룹에게 설계 가 명세서 에 부합되는 
가 그리고 명세서의 매 설명문이 설계의 일정한 부분에 반영되여 있는가를 검열하기 위 
한 강력한 도구를 제 공해 주고 있 다. 

설계심사는 명세서에서 진행하는 심사와 류사하다. 그러나 대부분의 설계문서의 기 
술적본성 으로 하여 의 뢰 자는 보통 참가하지 않는다. 설 계 림 과 SQA 그룹성 원들은 매 개 별 
적인 모둘은 물론 전반적인 설계를 하면서 설계가 정확하다는것을 담보해야 한다. 찾아 
야 할 오유류형 들에는 론리적오유, 대 면부오유，례외처 리(오유조건들의 처 리)의 결핍 그 
리 고 가장 중요한것 으로서 명세사항에서 의 불일 치 들이 포함된다. 이 밖에 심사림 은 일부 
명세오유들이 이 전단계 에서 는 발견되 지 않을 가능성 이 있 다는것 을 알고 있어 야 한다. 심 
사과정에 대한 상세한 설 명 은 6.2 에 서 주었다. 

2. 4. 2. 설계단계에서의 문서작성 

설계 단계의 기본결과물은 설계 그자체 인데 그것은 두 부분 즉 모둘에 의 한 제품서술 
인 구성방식설계와 매 모둘에 대한 서술인 상세설계로 이루어 진다. 상세설계는 실현단 
계를 위하여 프로그람작성 자들에 게 보내 여 진다. 제7장에서는 설계리 론을 일 반적 으로 서 
술하고 특히 는 객체설계를 서술하고 있다. 객체지향설계를 비롯한 설계 기 법들은 도형 및 
의사코드와 같은 설계를 서술하는 방법들과 함께 13장에서 서술하고 있다. 
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2. 5. 실현단계 

실현단계 에서 설계 를 구성하는 여 러 가지 구성 모둘들이 코드작성된다. 실현단계 는 14 
장과 15장에 서 상세 히 론의한다. 

2. 5. 1 . 실현단계에서의 시험 

모둘은 실현되는 동안 시험(탁상검열; cfesA ： 되여야 하며 모둘이 실현된 다음 

에 시험실례에 대하여 실행된다. 이러한 비형식적인 시험은 프로그람작성자들에 의하여 
진행된다. 그다음 품질보증그룹이 모둘들을 깐깐히 시험 한다. 여러가지 모둘시험기 법들은 
제14장에 서 서 술된다. 시 험실례 들을 실행하는것외 에 코드심 사는 프로그람작성오유를 발 
견하는 강력하고 성공적인 기법이다. 여기서 프로그람작성자는 모둘이 렬거된 순서로 심 
사 림 성 원들을 안내 하게 된 다. 심 사 림 에 는 SQA 의 대 표자가 포함되 여 야 한다. 처 리 절 차는 
앞서 언급한 명세작성과 설계단계의 심사와 류사하다. 다른 모든 단계에서와 같이 SQA 
그룹의 활동에 대 한 기록을 보관해 두어 야 한다. 

2. 5. 2. 실현단계의 문서작성 

실현단계와 련관된 중요한 문서작성은 적당한 주석을 준 매 모둘에 대한 원천코드이 
다. 그러나 프로그람작성자들은 코드를 시 험하는 모든 시험실례들과 기대되는 결과 및 
실 제 결 과들을 비 롯하며 유지 정 비 단계 를 지 원 하도록 보충적 인 문서 작성 을 제 공한다. 이 런 
문서 들은 2.7. 1 에 서 설 명 한바와 같이 회 귀 시 험 에 리 용된 다. 

2. 6. 통합단계 

다음단계는 모둘을 결합하고 제품전체로써 기능이 정확히 수행되는가를 결정하는것 
이다. 모둘이 통합되는 방법(한번에 모든 모둘을 통합하거나 또는 한번에 하나씩 통합하 
는 방법)과 특정한 순서(모둘호상련결도에서 하강식, 상승식)는 결과적인 제품의 품질에 
결정적인 영향을 줄수 있다. 실례로 제품이 상승식으로 통합된다고 가정하자. 어떤 기본 
적인 설계오유는 후에 나타나는데 이것은 많은 품을 들여 다시 작성되여야 한다. 반대로 
모둘이 하강식으로 통합된다면 보다 낮은 준위의 모둘들은 상승식으로 제품이 통합되는 
경우에 하게 되는 시험을 거치지 않게 될것이다. 이것과 기타 다른 문제들에 대하여서는 
제15장에 서 상세 히 서 술한다. 실현단계 와 통합단계 를 병 행하여 진행하여 야 하는 리유에 
대해서는 제2장에서 상세히 서술한다. 

2. 6. 1 . ■합단계에서의 시험 

통합시 험 / e 해 ng ) 의 목적 은 명세 서 를 만족시키 는 어 떤 제 품을 만들어 내 
기 위하여 모둘들이 정 확하게 결합되 여 있는가를 검 열하는것 이 다. 통합단계의 시험기 간 
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에 모둘의 대면부를 시험하는데 깊은 주의를 돌려야 한다. 중요한것은 형식인수들의 개 
수와 순서，형 이 실 제 인수의 개 수와 순서，형 과 일 치 하는것 이 다. 이 런 강력 한 형 검 열 [van 
Wijingaarden et al„ 1975] 은 콤파일 러 와 련결 프로그람에 의하여 만족스럽 게 수행 되 게 된 
다. 그러 나 많은 언어들은 류사성 이 강하지 못하다. 그러한 언어들이 리 용될 때 에는 대 
면부검열이 SQA 그롭성원들에 의하여 진행되게 된다. 통합단계에서의 시험이 완성되게 
되 면 SQA 그룹은 제 품시 험 을 진행하게 된다. 제 품전체 로서의 기 능검사는 명세서 에 준하 
여 진행되게 된다. 특히 명세서에 명시한 제약들이 시험되여야 한다. 하나의 전형적인 
실례는 응답시 간이 충분히 짧은가를 시 험하는것 이 다. 제품시 험의 목적 이 명세 가 정 확히 
실현되였는가를 결정하는것이기때문에 일단 명세서가 완성되면 대부분의 시험실례들이 
작성 된 다. 제 품의 정 확성뿐만아니 라 로바스트성 도 시 험 되 여 야 한다. 즉 제 품이 폭주되 는 
가 또는 제 품의 오유처 리 능력 이 나른 자료를 처 리하는데 적 합한가 하는것 을 결 정 하기 
위하여 고의 적 으로 잘못된 오유입 력 자료들이 제시된다. 만일 제 품이 현재 설 치된 의뢰 
자의 쏘프트웨어와 함께 동작하게 되면 시험은 새 로운 제 품이 의뢰 자의 현존 콤퓨터조 
작에 영 향을 주지 않는다는것 을 검 열할수 있도록 수행 되 여 야 한다. 마지 막으로 원천코 
드와 모든 다른 형태의 문서들이 완전하고 내부적으로 모순이 없는가에 대하여 검열하 
여야 한다. 제품시험은 15.4 에서 론의된다. 통합단계의 시험에서 마지막측면은 인수시험 
{acceptance to 切 jg) 이 다. 쏘프트웨 어 는 의 뢰 자에 게 배 포되 는데 의 뢰 자는 그것 들을 실제 
하드웨 어상에 서 시 험자료와 반대 되 는 실 제자료을 리용하여 그것 을 시 험한다. 개발림 과 
SQA 그룹이 아무리 주의를 돌렸다고 해도 본질에 있어서 인공적 인 시 험실례 들과 실제 자 
료사이 에 는 중요한 차이 가 있 다. 쏘프트웨어 제품은 그 제 품이 인수시 험 을 통과하기전에 
는 명세서를 만족시킨다고 간주될수 없다. 인수시험에 대해서는 15.5 에서 보다 상세히 
설 명 한다. 

COTS 쏘프트웨 어 (2.1) 의 경우에 제품시험 이 완성되 자마자 완성된 제품의 판본은 즉석 
에 서 시 험 하기 위하여 선 발된 장래 의 의 뢰 자들에 게 제 공되 게 된 다. 이 런 첫 번째 판본을 
알파판본 (a/ 夕뇨 이 라고 한다. 수정된 알파판본은 베 타관본 vera/on) 이 라고 한다. 

보통 베 타관본은 최종판본에 근사하다. 

COTS 쏘프트웨어 에서의 오유는 개 발회 사에 있어서 제 품이 팔리지 않는것 으로 하여 
막대한 손실 을 가져 다 준다. 될 수록 많은 오유들이 될 수록 빨리 발견되 도록 하기 위하여 
COTS 쏘프트웨 어개 발자들은 자주 즉시시험 이 어 떤 숨겨 진 오유들을 발견하리 라는 기 대 
를 가지고 선발된 회사들에 알파 또는 베타판본을 제공한다. 대신에 알파, 베타측에는 흔 
히 쏘프트웨어 의 배 포판에 대 한 자유로운 복사가 허 용되 여 있 다. 알파, 베 타시 험 에 참가 
한 회 사에 는 위 험 요소들이 포함된 다. 특히 알파시 험판본에 는 좌절과 시 간랑비 그리 고 자 
료기지 에 대 한 손상을 초래할 오유들이 내재되 여 있을수 있다. 그러 나 이 회 사는 자기의 
경 쟁 자들을 압도할수 있는 새 로운 COTS 쏘프트웨어 를 리 용하는데 서 첫 시 작을 떼 였 다. 
쏘프트웨어 기업체 들이 SQA 그롭에 의한 철저한 제품시험 대신에 잠정 적 인 의뢰 자들에 의 
한 알파시 험 을 리용할 때 때때 로 문제 가 발생한다. 비 록 서 로 다른 많은 장소에서 진행 
하는 알파시험이 보통 많은 오유들을 발현시킨다고 하여도 SQA 그룹이 제공할수 있는 방 
법론적인 시험을 대신할수는 없다. 
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2. 6. 2. ■합단계에서의 문서작성 


이 단계에서 작성된 문서는 제품전체에 대한 주석을 준 원천코드와 프로젝트전체에 
대한 시험실례 그리고 사용자지도서, 조작지도서, 자료기지지도서, 기타 지도서들로 구성 
된 다. 


2. 7. 유지정비단계 

일단 제품이 의뢰자에게 배포되면 일부 변경시켜야 할 문제들이 제기된다. 유지정비 
는 제품이 의뢰자의 콤퓨터에 설치된 다음에 마지 못해 수행하는 일이 아니라 초기부터 
계획해야 하는 쏘프트웨어개발공정의 필수적인 부분이다. 2.4 에서 설명한바와 같이 설계 
는 실현할수 있는 범위내 에서 는 이 후의 확장을 고려하여 야 한다. 코드작성 은 장래 의 유 
지정비를 념두에 두고 실행하여 야 한다. 결국 2.3 에서 강조한바와 같이 유지정 비 에는 기 
타 모든 쏘프트웨 어활동들을 결 합한것 보다 더 많은 자금이 소비 된 다. 그러 므로 유지 정 비 
는 쏘프트웨어생산에서 매우 중요한 측면으로 된다. 유지정비를 절대로 이후의 문제로 
취 급해서 는 안된다. 대 신에 전체 적 인 쏘프트웨 어개 발노력 은 불가피 한 장래 의 유지 정 비의 
효과를 최소화하는 방향에서 진행되여야 한다. 

유지정비에서 제기되는 공통적인 문제는 문서작성 또는 문서의 결핍이다. 최종기간 
에 준하여 쏘프트웨어 를 개 발하는 과정 에서 원래의 명세서 와 설계문서 는 자주 갱 신되지 
는 않으며 그것은 유지정 비림에서는 거의나 리용되지 않는다. 자료기지지도서 나 조작지 
도서와 같은 기타 문서들은 작성되지 않을수도 있다. 왜냐하면 관리자측은 제품을 의뢰 
자에 게 제때 에 배 포하는것 이 쏘프트웨어와 병 행하여 문서 를 작성하는것보다 더 중요하다 
고 결정 하기 때 문이 다. 많은 실례 들에 서 원천코드는 유지 정 비하는 사람에 게 제 공되 는 유일 
한 문서로 된다. 쏘프트웨어산업에서 자주 직원들이 교체되는것은 유지정비가 실행될 때 
원래의 개발자들이 그 기업체에 종사하지 않는다는 점에서 유지정비상황을 악화시킨다. 

유지정 비는 이 미 앞에서 언급한 리유와 16장에서 언급한 보충적 인 리유로 하여 쏘프 
트웨어생산에서 가장 어려운 도전적인 단계로 되고 있다. 

2. 7. 1 . 유지정비단계에서의 시험 

유지정비단계에서 어떤 제품에 대한 변경을 시험하는데는 두가지 측면이 있다. 첫째 
측면은 요구하는 변경이 정확히 실현되는가 하는 검 열 이다. 두번째 측면은 제품에 대하 
여 요구되는 변경을 실현하는 과정에 다른 우연한 변경이 발생하지 않는다는것을 담보하 
는것 이 다. 따라서 일 단 프로그람작성 자가 요구하는 변경 이 실현되 였 다는것 이 확정 되 면 
제품의 나머지 부분의 기능이 손상되지 않았다는것을 확증하기 위하여 제품을 이전의 시 
험 실례로써 시험 하여야 한다. 이러한 절차를 회귀 시험 (regmw/on 라고 한다. 회귀 시 

험를 지원하기 위하여서는 이전의 모든 시험실례들이 이 시험실례를 실행한 결과와 함께 
보존되여야 한다. 유지정비에서의 시험은 16장에서 보다 상세히 고찰된다. 
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2. 7. 2. 유지정비단계에서의 문서작성 

유지정비단계의 하나의 기본측면은 매 변경을 그 변경의 리유와 함께 기록하는것이 
다. 쏘프트웨어가 변경되면 회귀시험을 진행해야 한다. 따라서 회귀시험실례들은 이 단계 
에서 문서작성의 기본형식으로 된다. 

2. 8. 페 기 

쏘프트웨 어 개 발의 마지막단계 는 페 기 이 다. 여 러 해동안 봉사한후 그이상의 유지정 비 
에 더는 비용을 소비 할수 없는 단계 에 이르게 된다. 

1. 때때로 제안된 변경들이 너무 심하므로 전반적인 설계를 변경시켜야 한다. 이러 
한 경우에 전체적인 프로젝트를 다시 설계하고 다시 코드를 작성하는것은 비용 
이 더 적게 든다. 

2 . 원래의 설계를 너무 많이 변경시킨 결과 제품안에 본의 아니게 호상의존성이 발 
생할수도 있으며 지 어는 중요치 않은 하나의 모둘에 대 한 자그마한 변경 이 제품 
전반의 기 능에 심한 영 향을 미칠수도 있다. 

3. 문서 는 적 당하게 유지정 비 되 지 않을수도 있다. 결국 제 품을 유지정비하는것 보다 
또다시 코드작성하는것 이 더 안전할 정도로 회귀오유의 위 험성 이 증가하게 된다. 

4. 제 품이 실행 될 하드웨 어(또는 조작체 계)가 교체되 게 된다. 즉 수정하는것 보다도 
처 음부터 다시 작성하는것 이 더 경제 적 일수도 있다. 

이러한 모든 실례들에서 현재의 판본이 새로운 판본으로 교체되며 소트프웨어개발은 
계 속된 다. 

다른 한편 진정한 페기는 어떤 제 품을 리용할 필요가 없을 때 발생하게 되는 보기 
드문 사건이다. 의뢰자측은 제품이 제공하는 기능을 더이상 요구하지 않으며 마지막에는 
콤퓨터에서 제거되게 된다. 

이 와 같이 매 단계 들에 서 주목을 끈 일 부 난점 들과 함께 완전한 쏘프트웨 어개 발공정 
을 검토한 다음 쏘프트웨어생산전반과 관련된 난점들을 고찰해 보자. 

2. 9. 쏘프트웨어생산에서의 문제 : 

본질적인것과 우연적인것 

지난 50여년동안 하드웨 어 는 보다 값이 눅어 지 고 속도가 빨라 졌으며 크기 도 줄어 
들었다. 1950년대에 회사들은 오늘날 1,000딸라미만으로 팔리우고 있는 개인용탁상콤퓨터 
보다도 능력 이 약한 방만한 크기의 를퓨터를 사는메 이전 가격으로 수백만딸라를 지불하 
였다. 이러한 경향은 돌려 세울수 없으며 콤퓨터들은 끊임없이 더 작아 지고 더 빨라 지 
고 값이 더 눅어 질것 이다. 

그러나 사실은 그렇지 않다. 사실상 많은 물리적인 제약들이 앞으로의 하드웨어의 
크기와 속도를 제한하고 있다. 이 제약들중의 첫째가 빛의 속도이다. 전자，더 정확히 전 
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자기파는 초당 30만 km 보다 더 빨리 이 동할수는 없 다. 그러 므로 를퓨터 의 속도를 높이 는 
한가지 방도는 그것의 구성요소들을 소형화하는것이다. 이런 방식으로 전자들의 이동거 
리가 보다 짧아 지게 된다. 그러나 구성요소의 크기에 대한 보다 낮은급의 제한도 있다. 
전자들은 세개의 원자만한 폭을 가진 좁은 길을 따라서도 이동할수 있다. 그러나 전자들 
이 이동해야 할 길이 이것보다 더 좁으면 전자들이 어떤 린접한 길로 탈선할수 있다. 같 
은 리유로 하여 병 렬통로들은 서 로 너무 가까이 있어서 는 안된다. 이 렇게 빛의 속도와 
령이 아닌 원자의 너비는 하드웨어의 크기와 속도에 물리적인 한계를 준다. 우리는 아직 
이러한 한계에 도달하지 못하고 있다. 즉 콤퓨터는 물리적인 한계에 도달함이 없이 적어 
도 보다 빠르고 보다 작다는 두개의 등급으로 가를수 있다. 그러 나 자연의 고유한 법칙 
으로부터 전자콤퓨터를 임의로 빠르게 또는 임의로 작게 할수는 없다. 

그러 면 쏘프트웨어 의 경 우는 어 떤가? 쏘프트웨어 는 비 록 그것 이 늘 종이 나 디 스크와 
같은 어떤 물리적 인 매체 에 기록된다고 하더 라도 본질상 개 념적 이기때 문에 비물리적 인 
실체 이 다. 얼핏 보기 에 는 쏘프트웨어 로 그 무엇 이 나 다 할수 있을것 같다. 그러 나 흐레 드 
브룩스는《은총탄은 없다.》 [Brooks, 1986] 라는 제목의 기사에서 이러한 믿음을 깨뜨렸다. 
그는 하드웨어의 속도와 크기가 물리적으로 실현될수 없는 한계를 가지고 있는것과 류사 
하게 현재 의 쏘프트웨 어 생 산기 술로서 는 해 결 할수 없는 본질적 인 문제 들이 존재 한다는것 
을 밝히 였 다. 브룩스의 말을 인용하면 다음과 같다.《 쏘프트웨어 를 개 발하는것 은 어 려 운 
일이다. 사실상 은총탄은 없다.》(용어 은총탄에 대한 설명은 아래에 있는《 알고 싶은 
문제〉〉를 보시 오.) 


알고 싶 e ©제 


브룩스 의 기사의 제목에서 용어《은총탄》은 승냥이 갈은 사람 즉 다른 말로 . 잠 이로 
돌변한 사람들에 대 한 위 탁살인방법 을 가리키는 말이 다. 브룩스 의 질문의 방향은 류- -한 은 
총탄이 쏘 프트웨 어에 대한 문제들을 푸는데 리용될수 있지 않겠는가를 결정하는것 ® 다. 결 
국 쏘 프트웨 어는 일반적으로 단순하고 간단한것 같다. 그러 나 승냥이 같은 사람과 4찬가 
지로 쏘 프트웨 어는 늦어 진 최종기한과 초과된 예산안 그리고 시험에서 발견되 7 않은 
명세서와 설계에서의 잔류오유와 같은 형래로 그 어떤 무서운 존재로 전환될수 I 다. 


브룩스 의 기사《은총탄은 없다.》를 다시 고찰 해 보자. 

브룩스 의 론점은 쏘프트웨어의 본성으로부터 쏘프트웨어생산에서 제기되는 모든 문 
제들을 신기하게 해결할수 있는 은총탄은 발견되지 않을것 이며 더우기는 은총탄이 하드 
웨 어 분야와 견줄만한 돌파구를 쏘프트웨어 분야에 서 달성하는것 을 도울수 없 다는것 이 다. 
그는 쏘프트웨어의 난점을 두개의 아리스토텔레스범주로 나누었다. 즉 쏘프트웨어의 고 
유한 본성으로부터 나오는 고유한 난관을 본질 (e^ence) 적 인 난관으로 그리고 쏘프트웨어 
생산에서 고유하지 않은 오늘날 우연히 맞다들게 되는 난관들을 우연 (flccWen/) 적인 난관 
으로 간주하고 있 다. 즉 본질 적 인것 은 변화되 지 않는 그러한 쏘프트웨 어 생 산측면을 이 루 
고 있는 반면에 우연적인것은 돌파구나 은총탄을 연구하는데 복종해야 한다. 
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쏘프트웨어생산에서 어느 측면이 고유한 난관으로 되는가? 브룩스는 이에 대하여 네가지 
용어 즉 복잡성 (comp/ex 均/), 순응성 (COT?/bm 均，)，가변성 (c/wngeaW/ 均/)，비 가시성 沙)을 

렬 거하였 다. 브룩스가 복잡성 이라는 단어 를 리 용한것 은 그 용어 가 일 반적 으로 콤퓨터 과 
학에서 구체적 으로는 쏘프트웨 어공학에서 서 로 다른 여 러 가지 의미를 가지게 된다는 점 
에서 약간 적 당치 않다. 브룩스는《 복잡성》이 라는 단어 를《 복잡한》또는《 착잡한》 
이라는 의미로 사용하였다. 사실상 이 네가지 측면에 대한 이름들은 비공학적인 의미로 
리용되 고 있 다. 이 네 가지 측면들에 대 하여 고찰하기 로 한다. 

2. 9. 1 . 복 잡 성 

쏘프트웨어는 인간이 만들어 낸 다른 모든것들보다 더 복잡하다. 하드웨어는 쏘프트 
웨어에 비하면 거의나 단순한것이다. 이것을 살펴 보기 위하여 를퓨터의 주기억에서 하 
나의 16비 트 word 형자료 W 를 고찰하자. 매 비 트는 정 확히 값 0과 1을 취 할수 있기때 문 
에 word 형자료 W 는 전체 적 으로 216개 의 서 로 다른 상태 를 가질 수 있 다. 만일 두개 의 16 
비 트 word 형자료 W1 과 W2 가 있 다고 하면 W1 와 W2 가 가질 수 있 는 가능한 상태 의 수는 
216의 두제곱인 232개로 된다. 일반적으로 체계가 여러개의 독립적인 부분으로 구성되여 
있으면 그러한 체 계의 가능한 상태 들의 수는 매 구성 요소의 가능한 상태 수의 적 으로 된 
다. 콤퓨터 가 쏘프트웨어제품 P 를 동작시 키 고 16비 트 word 형자료 W 는 옹근수 표의 값을 
기억 하는데 리 용된다고 가정하자. 만일 표의 값이 read(X) 라고 하는 명령에 의 하여 읽어 
진다고 하면 옹근수 표는 216개의 서로 다른 값을 가질수 있기때문에 얼핏 보기에는 쏘 
프트웨어제품이 가질수 있는 상태의 수가 word 형자료가 가질수 있는 상태의 수와 꼭같이 
보일수 있다. 만일 제품 묘가 오직 하나의 명령 read(X) 로 구성되여 있으면 요의 상태수는 
꼭 216으로 될것 이 다. 그러 나 현실적 이 고 중요한 쏘프트웨어제 품에서 입 력 으로 되 는 변 
수의 값은 제품에 어디에선가 후에 리용되게 된다. read(X) 명령과 표의 값을 리용하게 되 
는 기 타 다른 명 령 들사이 에 는 독립 성 이 존재한다. 만일 제 품에 서 조종흐름이 표의 값에 
의존한다면 정황은 보다 더 복잡해 진다. 실례로 표가 switch 명령(분기명령)에서 조종변수 
로 되거나 또는 표의 값에 따라서 끝조건이 결정되는 for 순환 또는 while 문이 있을수 있 
다. 상태수에서 이러한 조합폭발의 결과로 하여 복잡성은 제품의 크기에 비례하여 선형 
적 으로 커 지 는것 이 아니 라 훨 씬 더 빨리 커 지 게 된다. 

복잡성 은 쏘프트웨어의 본질적 인 속성 이 다. 쏘프트웨어의 중요한 부분들이 어 떻게 
설계되는가에 관계없이 제품의 부분들은 호상작용한다. 실례로 모둘의 상태도 그것의 변 
수상태에 의존하며 대역변수(하나이상의 모둘에서 호출가능한 변수)들의 상태 또한 전반 
적인 제품의 상태에 영향을 준다. 실례로 객체지향파라다임을 리용하면 복잡성은 감소될 
수 있다. 그럼에도 불구하고 복잡성은 전체적으로는 제거될수 없다. 다른 말로 복잡성은 
쏘프트웨어 의 우연적 인 속성 은 아니 고 본질 적 인 속성 이 다. 

브룩스는 복잡한 현상이 수학 및 물리학과 같은 학문들에서 서술되고 설명될수 있다 
고 강조하였다. 수학자들과 물리학자들은 복잡한 체계의 본질적인 특성을 추상화하고 그 
러 한 본질적 인 특성 만을 반영하는 가장 간단한 모형 을 만들고 그 간단한 모형의 타당성 
을 증명하고 그로부터 예측하는 방법들을 체득하였다. 대비적으로 쏘 프트웨 어 가 단순화 
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되면 전체적 인 련습은 쓸모 없다. 즉 수학과 물리학에서의 단순화기법들은 그러한 체계 
의 복잡성 들이 쏘프트웨 어의 경우에서 와 마찬가지 로 본질적 인것 이 아니 라 우연적 인것 이 
기때문에 리용된다. 

쏘프트웨 어의 이 본질적 인 복잡성 이 중요한것으로 되는것은 제품을 리해하기 가 힘들 
어 진다는것이다. 사실상 큰 제품을 통채로 리해하는 사람은 없다. 이것은 개발림성원들 
사이에 불완전한 통신이 이루어 지게 하며 나아가서 대규모쏘프트웨어생산을 특징 짓는 
시간과 비용을 랑비하게 된다. 이밖에 명세에서의 오유는 제품전반에 대한 리해가 부족 
한것으로 하여 간단히 생기게 된다. 

이러한 본질적인 복잡성은 쏘프트웨어공정 그자체뿐아니라 공정관리에도 영향을 준 
다. 만일 관리 자가 관리 하는 개발공정 에 대하여 정확한 정보를 얻을수 없게 되면 프로젝 
트의 다음 단계들에서의 직원수요를 결정하고 정확한 예산안을 세우는것이 어렵게 된다. 
시간의 흐름과 앞으로의 최종기한과 관련한 고급한 관리에 대한 보고서는 정확치 못할 
수도 있다. 관리자나 관리자에게 보고하는 사람들이 미결건이 여전히 련관되여야 한다는 
것을 모르는 경우에 시험일정을 작성하는것은 어려워 진다. 그리고 만일 어떤 프로젝트 
성원이 떠나갔다면 그를 대신할 사람을 양성하는것이 고통스러울수 있다. 

쏘프트웨어의 복잡성에 대한 또 하나의 결론은 그것이 유지정비과정을 복잡하게 한 
다는것 이 다. 그림 1-2 에 서 보여 준바와 같이 전체 쏘프트웨 어노력 의 약 2/3가 유지 정 비 에 
돌려 진다. 유지 정 비하는 사람들이 제 품을 리해하지 못하면 교정유지 정 비 나 확장유지 정 
비 는 원래 의 유지 정 비 에 의하여 생 겨 난 손해 를 가시 기 위하여 이 후의 유지 정 비 가 요구 
되는것과 마찬가지로 제품에 손해를 줄수 있다. 지어 원래의 저자가 변경을 하였을 때 
부주의로 초래되는 이러한 종류의 손해의 가능성은 언제나 존재한다. 그러나 유지정비프 
로그람작성 자가 맹목적 으로 작업할 때 에는 정황이 더 욱 악화된다. 문서 가 불충분하거 나 
더 우기 문서 가 없거 나 문서 가 부정 확한것 은 흔히 유지 정 비 를 정 확히 수행하지 못하게 하 
는 기 본원 인으로 된 다. 그러 나 아무리 문서 작성 이 잘되 였 다고 하더 라도 쏘프트웨어 의 고 
유한 복잡성은 그것에 대처하기 위한 모든 시도들을 초월하고 있다. 즉 이러한 복잡성은 
유지 정 비 에 부정 적 인 영 향을 주고 있다. 또한 객체 지향파라다임 은 복잡성 을 감소시 킬수 
있지만(이로 하여 유지정비를 개선한다.) 그것을 완전히 없앨수는 없다. 

2. 9. 2. 순 응 성 

수동적으로 조종되는 금제련소들이 콤퓨터화되게 된다. 일련의 단추들과 조종간에 
의하여 제철소를 조종하는 대신에 제철소의 구성부분들에 콤퓨터로부터 필요한 조종신호 
들을 보낸다. 비록 제련소가 원만하게 운영되고 있다할지라도 경영자들은 콤퓨터화된 조 
종체 계 가 금생 산을 증대 시 킬것 이 라고 생 각한다. 쏘프트웨 어 개 발림 의 과제 는 현존 기 업 소 
와의 대면부를 실현하는 제품을 개발하는것이다. 즉 쏘프트웨어는 기업소에 복종해야 하 
며 기업소는 쏘프트웨어에 복종하지 않는다. 이것은 브룩스가 정의한 첫번째 류형의 순 
응성인데 여기서 쏘프트웨어는 현존체계와 대화를 진행하여야 하기때문에 불필요한 복잡 
성을 초래한다. 

새로운 를퓨터화된 금제련소가 건설되였다면 어쨌단 말인가? 기계기사들과 금속기사, 
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쏘프트웨 어 공학자들이 모두 기계와 쏘프트웨 어 가 본질적 이면서도 단순한 방법 으로 맞아 
떨어 지도록 제 련소설계를 제의 하여 야 할것 같다. 그러 나 사실상 일반적 으로 쏘프트웨 어 
대면부를 다른 요소들에 복종시키는것은 다른 요소들이 이전에 구성된 방식을 변경시키 
기보다 쉽다는 느낌이 든다. 결국 금제련소의 다른 기사들도 이전과 같이 기계를 설계할 
것을 주장할것이며 쏘프트웨 어는 하드웨어대면부와 일치해야 한다. 이것이 브룩스가 정 
의한 두번째 류형의 순응성인데 여기서는 쏘프트웨 어가 가장 일치한 구성부분이라고 하 
는 그릇된 견해로 하여 쏘프트웨 어는 불필요 한 복잡성을 초래하게 된다. 

이러한 강제적인 순응성으로 하여 제기되는 문제들은 쏘프트웨어를 재설계하는것으 
로는 퇴치할수 없다. 왜냐하면 복잡성이 쏘프트웨어 그자체의 구조에 기인되지 않기때문 
이다. 대신에 그것은 쏘프트웨어설계가들에게 부과된 사람 또는 하드웨어에 대한 대면부 
에 의해서 초래되는 쏘프트웨어의 구조에 기인된다(앞으로 이것들이 어떻게 변화되는가 
하는 세부에 대해서는 다음의 《알고 싶은 문제〉〉를 보시오.). 


알:2 싶 e ©제 

1.4 에 의하면 스타 트랙 크 스타쉬 프 U . S . S 회 사에 대 한 기 술지 도서 NCC - l : I 1- D 의 
15~17폐지에서는 많은 쏘프트웨 어생산이 하드웨어가 개 발되기전에 시작된디 는것을 
서술하고 있다 [Stembach and Okura , 1991]. 이러한 관점에서 스타 트랙 크가 과학적인 S ■상이 
아니 라 과학적 인 사실 로 되 기 를 바란다. 


2. 9. 3. 가 변 성 

1.1 에서 지적한바와 같이 일반기사들에게 다리를 556 km 옮기거나 90° 회전시킬것을 
요청 한다면 리성 이 없다고 생각할수 있지 만 5년이내 에 조작체 계의 절반을 다시 만들라고 
쏘프트웨 어공학자들에 게 말하는것 은 완전히 타당하다. 일 반기 사들은 다리 의 절 반을 다시 
설 계하는것 이 품이 들고 위 험 하다는것 을 알수 있 다. 왜 냐하면 다리 를 처 음부터 다시 건 
설 하는것 이 비 용이 적 게 들고 안전하기 때 문이 다. 쏘프트웨 어공학자들은 오랜 기 간의 실 
천을 통해 그것을 잘 알고 있다. 그리고 유지정비를 확장하는것이 무분별하며 제품을 처 
음부터 다시 작성하는것 이 흔히 품이 적 게 든다는것 을 인정할것 이 다. 그러 나 의 뢰 자들은 
흔히 쏘프트웨어 에 대 한 변경 를 요구한다. 

브룩스는 쏘프트웨어의 변경 이 늘 강요된다는것 을 지 적하였 다. 결국 쏘프트웨어 가 
동작시 키 는 하드웨 어 를 변경 시 키 는것 보다도 쏘프트웨어 자체 를 변경 시키 는것 이 더 쉽다. 
즉 그것은 용어 쏘프트웨어 가 하드웨 어 의 리 면에 놓여 있는 리유와 관련된다. 이 밖에 체 
계의 기능은 쏘프트웨어 에 포함되 여 있으며 기 법 에서의 변경 은 쏘프트웨어의 변경 으로 
실현된다. 빈번하고 철저한 유지정 비 에 의하여 제 기 되는 문제들은 단지 무식 에 의해서 
초래 되 는 문제 들이 며 만일 사회 전 반이 쏘프트웨어 의 본질 을 더잘 알게 된 다면 기 본변경 
에 대한 요구가 발생하지 않을것이라는것이 제기되였다. 그러나 브룩스는 가변성이 쏘프 
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트웨어의 본질에 대한 속성이며 극복할수 없는 고유한 문제이라는것을 강조하였다. 즉 
쏘프트웨어의 중요한 성질은 대중의 교육정도에는 관계없이 쏘프트웨어의 변경은 언제나 
강요되며 흔히 이러한 변경들이 철저하게 진행된다는것이다. 쓸모 있는 쏘프트웨어가 변 
경되여야 할 리유를 다음과 갈은 네가지로 말할수 있다. 

1. 1.3 에서 지 적한바와 같이 쏘프트웨어 는 현실에 대 한 모형이 며 현실 이 변화될 때 
쏘프트웨어 는 그에 적 응되 든가 또는 사멸 되 여 야 한다. 

2. 만일 쏘 프트웨 어 가 쓸모 있다고 인식 되면 원래설계 에 의하여 실현가능한 기능을 
초월하여 제품의 기능을 확장하도록 주로 사용자들의 요구를 만족시키는 변경을 
할수 있어야 한다. 

3. 쏘프트웨어 의 가장 큰 한가지 우점 은 쏘프트웨어 가 하드웨 어보다 훨씬 더 변경 
시키기 쉽다는것이다. 

4. 성 공적 인 쏘프트웨어 는 그 쏘프트웨어 를 작성한 하드웨 어 의 생 명 주기 를 초월 하 
여 잘 유지된다. 왜냐하면 흔히 4〜5년후에는 하드웨어가 이전처럼 기능을 잘 
수행하지 못하기 때 문이 다. 그러 나 보다 중요한것은 기 술적 인 변경 이 너무 빨라 
서 보다 용량이 큰 디 스크, 보다 빠른 중앙처 리 소자 또는 보다 강력한 현시장치 
와 갈은 적 당한 하드웨 어 의 구성 부분들 이 쏘프트웨어 가 존재해 있 는 동 안은 쓸 
모가 있다는것 이 다. 일반적 으로 쏘프트웨어는 새 로운 하드웨 어상에서 실행될수 
있을 정도로 변경되여야 한다. 

이런 리유로 쏘프트웨어의 한가지 본질은 그것이 변경되여야 한다는것이며 이러한 
지 속적 이 고 계 속적 인 변경 은 쏘프트웨어 의 품질 에 부정 적 인 영 향을 준다. 

2. 9. 4. 비가시성 

쏘프트웨어의 본질과 관련하여 제기되는 중요한 문제는 그것이 《보이지 않는다는것 
과 볼수 없 다는것》이 다. 2 W 폐 지 의 목록을 넘 겨 받고 쏘프트웨 어 를 어 떤 방법 으로 변경 
시키라는 과업을 받은 사람은 브룩스의 의도를 정확히 알고 있다. 유감스럽게도 완전한 
제 품이 라든가 그 제 품에 대 한 어 떤 측면의 개 관을 표현하기 위한 만족스러 운 방도는 없 
다. 이 와 대 조적 으로 례하면 건축가는 건설 해 야 할 구조물의 매 세 부를 반영하는 2차원 
설계 도와 기 타 다른 상세한 도식 들뿐아니 라 설계 전반에 대 한 착상을 주는 3차원모형 을 
제 공할수 있 다. 화학자들은 분자들의 모형 을 만들수 있 고 공학자들은 축척 모형 을 구성할 
수 있으며 정형외과의사들은 환자들에게 자기들의 얼굴이 외과수술후에 어떻게 보이겠는 
가를 정 확히 보여 주기 위하여 콤퓨터 를 리용할수 있 다. 선도들은 규소소편과 기 타 다른 
전 자요소들의 구조를 반영하도록 그려 질 수 있 다. 즉 콤퓨터 의 구성 요소들은 여 러 가지 
추상화준위 에 서 여 러 종류의 도식 들에 의하여 표현될 수 있 다. 

확실 히 쏘프트웨 어공학자들은 자기 들의 제 품에 대 한 특정한 견해 를 표현 할수 있는 
방법들을 가지고 있다. 실례로 쏘프트웨어공학자는 첫번째는 조종흐름을 보여 주고 두번 
째 는 자료흐름을 보여 주며 세 번째 는 의 존관계 의 형 태 를，네번째 는 시 간흐름을 나타내 는 
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방향그라프들을 그릴수 있 다. 또한 UML 선도 (12, 13장)는 대 규모쏘프트웨어 의 구조를 서 
술하는 위력한 도구로 인정되였다. 문제는 이러한 그라프들이 거의나 평면적이고 더우기 
는 계층적이 아니라는것이다. 이러한 그라프들에 있는 많은 교차점들은 리해하는데서 명 
백히 장애 로 된 다. 파나스는 하나 또는 그이 상의 릉들이 계 층구조를 이룰 때 까지 그라프 
의 릉들을 잘라 낼 것 을 제 안하였 다 [ Parnas , 1979]. 문제 는 결 과적 인 그라프가 리 해 하기 쉽 
다고 할지 라도 그것 은 쏘프트웨어 의 한 부분만을 볼수 있게 하며 잘라 낸 릉들이 쏘프 
트웨어의 구성요소들속에 존재하는 호상련관을 리해하는데서 결정 적 이 라는것 이 다. 이 와 
같이 쏘프트웨어를 표현할 능력이 결여되여 있는것으로 하여 결국 쏘프트웨어를 리해하 
기 어 려울뿐아니 라 쏘프트웨어 전문가들사이 의 정 보전달이 심 히 장애 된 다. 즉 200페 지 의 
목록을 변경해 야 할 변경 목록과 함께 동업 자들에 게 념 겨 주기 위한 대 안은 없는것 갈다. 

흐름도표，자료흐름도(11.3.1)，모둘호상접속도 또는 UML 선도 (12, 13장)와 같은 모든 
종류의 시 각화수단들은 제품의 어떤 측면을 시 각화하기 위한 매우 유용하고 강력한 수단 
으로 된다. 시각적인 표현들은 다른 쏘프트웨어공학자들은 물론 의뢰자들과도 정보전달 
을 진행하기 위한 훌륭한 수단으로 된다. 문제는 이러한 도식들이 제품의 모든 측면들을 
구체적으로 표현할수 없으며 제품에 대한 어떤 하나의 시각적 인 표현들에서 무엇이 빠졌 
는가를 결 정 하는 방법 이 없 다는것 이 다. 

2. 9. 5. 은총탄은 없는가 

브룩스 [ Brooks , 1986] 의 기 사가 결코 완전히 막연한것 은 아니 다. 그는 쏘프트웨 어 기 술 
에서 세개의 주요한 돌파구가 있다고 서술하였다. 즉 고급언어，시분할, 쏘프트웨어개발 
환경 ( UNIX 프로그람작성 자들의 작업 대 ( wor 해 e « c /0 와 같은)이 있 다는것 을 서 술하였지 만 그 
것들은 다만 비본질적이며 우연적 인 난관들만을 해결할수 있다고 강조하였다. 그는 정 확 
성증명(6.5)，객체지향설계 (13 .句， Ada 와 인공지능 및 전문가체계를 비롯한 여러가지 기술 
개발들이 현재 잠재적인 은총탄을 릉가하고 있다고 평가하였다. 비록 이러한 일부 방법 
들이 우연적인 난점들을 미해결로 남겨 둔다고 하더라도 브룩스는 그것들이 본질적인 난 
점 들과는 상관이 없 다고 간주하였 다. 앞으로 비 교가능한 돌파구를 성 취 하기 위하여 브룩 
스는 쏘프트웨어를 개 발하는 방법 을 바끌것을 제 기하였다. 실례 로 가능할 때마다 쏘프트 
웨 어 제 품들은 주문제 품이 아니 라 규격 제 품(즉 COTS 쏘프트웨 어 ) 으로 판매 되 여 야 한다. 브 
룩스의 견해 에 의하면 쏘프트웨어 를 개 발하는데 서 어 려 운 부분은 실현단계 가 아니 라 요 
구사항확정단계와 명세작성단계, 설계 단계 에 있다. 그에게 있어서 신속원형작성의 리용은 
(10.3) 큰 개 선을 이 룩하기 위한 중요한 원천으로 되 고 있 다. 브룩스의 제 안에 서 제 품생 
산성을 크게 개선하기 위한 또 다른 하나의 방안은 증식개발원리를 보다 적극적으로 리 
용하는것인데 여기서는 제품을 전체적으로 개발할 대신에 계단식으로 개발해 나간다. 이 
개념에 대해서는 5.1 에서 서술한다. 

브룩스는 쏘프트웨어생산을 개선하는데서 주요돌파구를 열기 위해서는 훌륭한 설계 
자들을 양성 하고 고무격 려하는것 이 필 요하다고 하였 다. 이 미 언급하였지 만 브룩스가 제 
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안한 쏘프트웨어생산의 가장 어려운 측면의 하나는 설계단계이다. 그리고 훌륭한 설계를 
작성하려면 능력 있는 설계가들이 있어야 한다. 브룩스는 과거에 인기를 끈 제품들로서 
UNIX , APL , Pascal , Modular -2, SmallTalk 그리고 FORTRAN 을 렬거 하고 있다. 그는 그 生 
프트웨어모두가 한명 또는 몇명의 대 가들이 만든 제 품들이라는것 을 지적하였다. 다른 한 
편 COBOL , PL / I , ALGOL , MVS /360 그리고 MS - DOS 와 같은 보다 단조로우나 쓸모 있는 
제 품들은 위 탁제 품들이 였 다. 브룩스의 견해 에 의하면 만일 쏘프트웨 어 생 산을 개 선하려 고 
하는 경 우에 설계대 가들을 양성 하는것 이 가장 중요한 목표로 된다. 

브룩스 의 기사를 읽으면 사기가 떨어 진다. 그는 제목에서부터 현대 쏘프트웨어생산 
의 고유한 본성(본질)은 은총탄을 찾아 낼 가능성을 미 심쩍 게 한다는것을 서 술하고 있다. 
그럼 에도 불구하고 그는 만일 신속원형작성과 증식구성기 법의 리용 그리 고 설계대 가를 
양성 하는것을 통하여 어 디서 나 살수 있는 기성쏘프트웨어를 사들이는것 으로써 쏘프트웨 
어 생 산전략을 변경 시 킨다면 쏘프트웨어의 생 산성 이 제 고될것 이 라고 결론을 지 었 다. 그러 
나 큰 돌파구 즉《은총탄》은 거의나 없는것 갈다. 브룩스 의 비 관에 대 하여 투시적 으로 
고찰해 볼 필요가 있 다. 지난 20년동안 쏘프트웨 어 산업 은 해 마다 약 6%정 도씩 생 산이 
확고히 장성하였 다는것 을 보여 주었 다. 이 생 산장성 은 많은 제 조산업 들에 서 관측된것 들 
과 견줄만하다. 그러 나 브룩스 가 요구하는것은《은총탄》즉 생산성 에서 큰 생산장성을 
빨리 실 현 하기 위한 방도이 다. 하루밤사이 에 두배 의 생 산성 을 기 대할수 없 다고 하는 그 
의 견해 에 동의하지 않을수 없 다. 동시 에 6%의 배장성률은 생 산성 이 12년만에 2배 로 된 
다는것을 의미한다. 이 러한 개선은 우리가 만족할만큼 신속하고 극적 인것은 못되지만 쏘 
프트웨어공학과정 은 해 마다 확고하게 개 선되 고 있 다. 

이 장의 나머지부분에서는 공정개선을 목적으로 하는 국가 및 국제적 인 시도에 대하 
여 설 명한다. 


2.10. 쏘프트웨어개발공정의 개선 

전반적인 경제는 콤퓨터와 쏘프트웨어에 결정적으로 의존하고 있다. 그러므로 많은 
나라들에 서 쏘프트웨 어개 발공정 에 관심 을 돌리 고 있 다. 실례 로 1987년에 미 국방성 ( DoD ; 
Department of Defence ) 은 다음과 같이 보고하였 다. 《 새 로운 쏘프트웨 어 방법 론들과 기 법 
을 적 용함으로써 이 루어 지는 생산성과 품질리득에 대 하여 아직 리행되지 않는 계 약을 
체결한 때 로부터 20년이 지 나서 산업 및 정부기구들은 기본문제 가 쏘프트웨 어개 발공정 을 
관리 할 능력 이 없 다는것 이 라는것 을 깨 닫고 있 다. > [ DoD , 1987]. 

이것과 그와 련관된 사건들에 대응하여 DoD 는 쏘프트웨어공학협회 ( SEI ; Software 
Engineering Institute ) 를 창설하고 그것을 경쟁적인 조달과정에 기초하여 피츠버그에 있는 
카네 기 멜 론종합대 학에 설 치하였 다. SEI 의 하나의 중요한 성 공은 능력 성 숙도모형 ( CMM ) 의 
시 도였 다. 쏘프트웨 어 공정 개 선과 관련된 노력 에 는 국제 규격 화기 구의 ISO 9000계 렬 규격 과 
ISO/IEC 15504 그리 고 40여 개 나라를 망라하는 국제 적 인 쏘프트웨 어 개 선시 도들이 포함되 
여 있다. 우선 능력성숙도모형 ( CMM ) 을 서술하자. 
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2.11. 능력성숙도모령 

SEI 의 능력 성 숙도모형 ( CMM ; Capability Maturity Model ) 은 리 용되 는 실제 의 생 명 주기 
모형 과는 상관없 이 쏘프트웨 어개 발공정 을 개선하기 위한 전략들의 련관된 그룹이 다(용어 
《성 숙도》는 공정 그자체의 우수성에 대한 척도이다.》. SEI 는 쏘프트웨어를 위한 
CMM ( SW - CMM ), 인적 자원의 관리를 위한 CMM ( P - CMM , 여기서 P 는《 사람》을 나타낸 
다.》，체 계공학을 위한 CMM ( SE - CMM ), 통합제품개 발을 위한 CMM ( IPD - CMM ) 그리 고 
쏘프트웨어 획 득을 위한 CMM ( SA - CMM ) 을 개 발하였 다. 모형 들과 어 떤 필 연적 인 과잉준위 
사이 에 는 일 련의 불일 치 가 존재한다. 따라서 1997년에 성 숙도모형 을 위한 하나의 독립 적 
인 통합틀 즉 능력 성 숙도모형 통합 ( CMMI ) 을 개 발하기 로 결정하였 다. 우에 렬 거 한 5개 의 
능력 성 숙도모형가운데 서 4개 의 모형 이 CMMI 에 통합되 였 으며 SA-CMM 은 후에 병 합되 는 
것 으로 되 였 다. 추가적 인 학문들은 앞으로 보충될수 있 다 [ SEI , 2000]. 지 면상의 리유로 하 
여 여기서는 하나의 능력성숙도모형 SW-CMM 만을 설명하기로 한다. SW-CMM 은 1986년 
에 와트흠흐레이 가 처 음으로 내 놓았다 [ Humphrey , 1989]. 쏘프트웨 어개 발공정 은 활동과 기 
법 그리 고 쏘프트웨어 를 개 발하는데 리용되 는 도구들을 내 포하고 있 다는것 을 상기해 보 
자. 결 국 그것 은 쏘프트웨 어생 산의 기 술적 인 측면과 관리 적인 측면을 다 병 합하고 있 다. 
SW-CMM 의 기 초를 이 루고 있는것 은 쏘프트웨 어개 발공정 을 관리해 나가는 방법 에 의하 
여 문제들이 초래되기때 문에 새 로운 쏘프트웨어 기법의 리용이 그자체 로서는 생산성과 수 
익성 을 증가시키 는 결과를 초래하지 않는다는 믿음이 다. SW-CMM 전략은 기술적 인 개선 
이 어 떤 본질 적 인 결 과로 될 것 이 라고 믿 고 쏘프트웨 어개 발공정 관리 를 개 선하게 된 다. 개 
발공정 전반에서의 개 선은 품질 이 보다 좋은 쏘프트웨어 를 생 성하며 또 시 간과 가격 이 초 
과되는것 으로 하여 애를 먹게 되는 몇개의 쏘프트웨 어프로젝 트를 산생시키게 된다. 

쏘프트웨 어개 발공정의 개 선이 하루밤사이 에 일 어 날수 없 다는것 을 념두에 두면서 
SW-CMM 은 변경 이 증가적 으로 진행 되 도록 한다. 보다 명 백하게 5개 의 각이한 성 숙준위 
가 정의되며 어떤 개발기업체는 개발공정의 보다 높은 준위를 향하여 일련의 작은 진화 
단계를 거쳐 서서히 전진하다. 이러한 접근방법에 대한 리해를 돕기 위하여 5개의 준위 
에 대하여 서술한다. 

성숙준우 I 1. 초기준위 이것은 가장 낮은 준위로서 본질적으로 건전한 쏘프트웨어공학 
에 대한 관리실천은 기업체에 있다는것이 아니다. 대신에 모든것이 림시적인 기초우에서 
진행된다. 유능한 관리자에 의하여 지휘되는 특정한 프로젝트와 홀륭한 쏘프트웨어개발 
림은 성공적 이 다. 그러나 보통의 패턴은 일반적으로는 건전한 관리가 그리고 특수하게는 
계 획 작성 의 결 여 로 인 하여 생 기 게 되 는 시 간과 가격 의 과잉 초과이 다. 결 과 가장 좋은 활 
동은 미 리 계 획된 과제 가 아니 라 중대한 국면들에 대 한 대 응들이다. 1준위 에 있는 기 업 
체 들에 서 쏘프트웨 어개 발공정 은 예 측할수 없 다. 왜 냐하면 그것 이 현재 의 지 휘 자에 전적 
으로 의존하기때문이다. 즉 지휘자가 변경될 때 그에 따라 개발공정도 변화된다. 결과 제 
품을 개발하는데 걸리는 시간이라든가 또는 비용과 같은 중요한 항목들을 정확히 예측할 
수 없게 된다. 

유감스러운것은 세계적으로 대부분의 쏘프트웨어기업체들은 모두가 아직 1준위에 해 
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당한 기 업 체 들이 라는것 이 다. 

성숙준우 I 2. 반복준위 이 준위 에서는 기초적 인 쏘프트웨 어 프로젝트 관리 실 천이 진행되 
게 된다. 계획작성과 관리기법들은 류사한 제품에 대한 경험에 기초한다. 따라서 그 이 
름을 반복0^〜 toWe ) 준위 라고 하였다. 2준위 에서는 적 당한 개 발공정 을 달성 하는데서 본 
질적인 첫 단계인 측정이 진행된다. 전형적인 측정은 비용과 일정계획을 주의 깊게 추적 
하는것을 포함하게 된다. 1준위에서와 갈은 위험한 방식으로 기법을 수행하는 대신에 관 
리 자들은 문제 가 발생할 때 문제를 식 별하고 닥쳐 올 위 험을 막기 위하여 즉시 적 인 정정 
작용을 취하게 된다. 중요한 점은 측정을 하지 않고서는 그들이 그 문제에서 손을 떼기 
전에 는 그러한 문제 들을 발견할수 없다는것 이 다. 또한 하나의 프로젝 트 기 간에 취 해 진 
측정 은 앞으로의 프로젝 트를 위한 실제 적 인 기 한과 비 용에 대 한 일정 을 작성하는데 리용 
될수 있다. 

성숙준우 I 3. 정의준우 I 3준위 에 서 쏘프트웨 어 제 품개 발을 위한 공정 은 완전히 문서 화된 
다. 개 발공정 에 대 한 관리적인 측면과 기술적 인 측면들이 모두 명백히 정의되고 가능한 
모든 곳에서 공정 을 개 선하기 위한 노력 이 계 속 진행 된다. 검 토 (6.2) 는 쏘프트웨어 의 품 
질을 달성하는데 리 용된다. 이 준위 에서는 앞으로 품질과 생산성을 높이기 위하여 CASE 
개 발환경 (5.6) 과 갈은 새 로운 기 술을 도입하는것 이 의 의 있 다. 대 조적 으로 《 고도기 술》 
은 위험구동 1준위공정을 보다 더 혼돈되게 만든다. 

비 록 많은 기 업체 들에서 성 숙준위 2와 성 숙준위 3에 도달하였다고 할지 라도 몇개 기 
업체들만이 성숙준위 4와 성숙준위 5에 이르고 있다. 그렇기때문에 이 두개의 가장 높은 
준위는 앞으로의 목표로 된다. 

성숙준우 I 4. 관리준위 4준위의 기업체들은 매개의 프로젝트에 대해서 품질과 생산성 
에 대한 목표을 설정한다. 이 두가지 량은 련속적으로 측정되며 허용할수 없는 목표로부 
터 의 리탈이 존재할 때 정 정작용이 취 해 진다. 통계 적 품질조종 [ Deming , 1986; Juran , 1988] 
은 관리자측이 품질이나 생산표준에 대한 중요한 위반으로부터의 탈선을 구별할수 있도 
록 하는데서 적합하다(통계적인 품질조종의 크기에 대한 실례는 1,000행이 되는 프로그 
람코드에서 발견되는 오유의 수로 된다.). 

성숙준위 5. 최량화준위 5준위에 해당되는 기업체들의 목표는 련속적인 공정개선이다. 
통계 적 인 품질과 공정조종기법 들은 기 업체를 인도하는데 리 용된다. 매 프로젝트로부터 
얻게 되는 지식은 앞으로의 프로젝 트에서 리용되 게 된다. 이 리하여 개 발공정 은 정의 반 
결합고리를 병합하여 생산성과 품질에 있어서 확고한 개선을 가져 오도록 한다. 


| 5. 최량화준위 

| 공정조종 | 

4.관리 준위 공정측정 

! 3.정의준위 I 

공정정의 1 

2.반복준위 

기초프로젝트관리 

| 1.초기준위 | 

특정 한 공정 | 


그림 2-1. 능력성숙도모형의 5 개의 준위 
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이러한 5개의 성숙준위들에 대하여 그림 2-1 에 개괄하여 보여 준다. 

쏘프트웨 어개 발공정을 개선하기 위하여 기 업체는 우선 현재의 개 발공정을 리 해해 야 
하며 그다음 앞으로의 개발공정을 형식화하기 위하여 시도한다. 그다음 이러한 개발공정 
개선을 실현하기 위한 작용들이 결정되고 우선권순위로 정렬된다. 마지막으로 이러한 개 
선을 실험하기 위한계획이 작성되고 실행된다. 개발기업체가 그다음 쏘프트웨어개발 
공정을 련속적으로 개선해 나아감에 따라 이러한 단계들이 되풀이된다. 즉 이와 갈은 높 
은 준위에로의 진보과정을 그림 2-1 에 보여 주었다. 능력성숙도모형으로부터 얻은 경험 
은 성숙준위를 완전히 달성하는데 보통 18개월부터 3년이 걸리 나 1준위에서 2준위로 이 
행하는데는 때 로는 3년 또는 지 어 5년까지 걸 린다는것을 보여 주었다. 이것은 지금까지 
순전히 현재 까지 도달한 기 초 또는 반작용적 인 기 초우에 서 기 능을 수행하여 온 어 떤 기 
업체 에 조직적 인 방법 을 점 차적 으로 도입하는것 이 하는것 이 얼마나 어 려운것 인가를 반 
영하고 있다. 

매 개의 성숙준위 에 대 하여 SEI 는 개 발기 업 체들이 그다음 성숙준위 에 도달하기 위하 
여 자기의 노력으로써 다음의 성숙준위 에 도달하기 위한 일련의 중요한 개 발공정 령역들 
을 강조하고 있다. 실례 로 2준위(반복준위)에서의 중요한 공정 령역 에는 구성조종 (5.8) 과 
쏘프트웨 어 품질 보증 (6 丄1)，프로젝 트계 획 작성 (9 장)，프로젝 트추적 (9.2.5) 그리 고 요구사항관 
리 (10 장)가 포함된다. 이러한 령역들은 쏘프트웨어관리의 기초적인 요소들을 포함한다. 
즉 의뢰 자의 요구(요구사항관리)를 결정하는것，계획을 작성하는것(프로젝트계 획작성)，이 
계 획 으로부터 리랄을 감시 하는것 (프로젝 트추적 )，쏘프트웨어 제 품을 구성하는 여 러 가지 요 
소들을 조종하는것(구성관리) 그리고 제품에 오유가 없다는것을 담보하는것(품질보증)들 
이 포함된다. 매개의 중요한 공정령역내에는 달성되는 경우에 도달되는 다음의 성숙준위 
를 생성하는 2~4개의 련관목표들의 그룹이 존재한다. 실례 로 하나의 프로젝 트계 획 작성목 
표는 쏘프트웨 어개 발활동을 적 당하게 현실적 으로 포함하는 계 획의 개 발이 다. 

가장 높은 준위 인 성 숙준위 5에 서 중요한 공정 령역 들에 는 결 함방지，기 술혁 신공정변 
화관리 가 포함된다. 두개 준위의 중요한 공정 령역들을 비 교하여 보면 5준위기 업체 들은 2 
준위기 업 체들보다 훨씬 앞섰다는것 이 명백하다. 실례 로 2준위기 업 체는 오유를 발견하고 
정 정하는 (쏘프트웨 어 품질은 6장에서 보다 더 자세 히 론의 된다.). 쏘프트웨 어 품질보증과 
관련된다. 이와 대비적 으로 5준위기 업체들에서 진행하는 공정은 결함방지 즉 쏘프트웨 어 
안에 첫째 로 오유가 없다는것을 담보하기 위한 시도를 포함하고 있다. 기 업체들이 보다 
더 높은 성 숙준위 에 이 르도록 하기 위 하여 SEI 은 어 떤 SEI 림 의 평 가를 위 한 기 초로 되 는 
일련의 질문철을 개발하였다. 평가의 목적은 해당 기업체의 쏘프트웨어개발공정에서 현 
재의 결함들을 강조하고 기 업체 가 그러한 공정 을 개선할수 있는 방도를 제시하여 주는것 
이 다. 쏘프트웨 어공학협 회 의 CMM 계 획 은 미 국방성 에 의하여 발기 되 였 다. CMM 계 획 의 원 
래의 목적의 하나는 국방성쏘프트웨어 를 생산하는 계 약자들의 공정 을 평 가하고 어떤 완 
성 공정 을 보여 주는 이 계 약자들에 대 한 계 약을 중재함으로써 방어쏘프트웨어 의 질을 높 
이는것이였다. 미공군은 자기의 계약대방으로 되려고 하는 모든 쏘프트웨어개발기업체들 
은 1998년까지의 SM-CMM 3준위를 준수하여 야 한다는것을 규정하였으며 뒤 이어 국방성 
전체 가 류사한 지 침을 시 달하였다. 이 리하여 개 발기 업체들은 자기 들의 쏘프트웨 어개 발공 
정 을 완성 하기 위한 개 선시 도에 서 압력 을 받게 되 였 다. 그러 나 SM - CMM 계 획 은 국방성쏘 


69 



프트웨어를 개선하기 위한 제한된 목표를 훨씬 넘어 섰으며 쏘프트웨어품질과 생산성을 
개선하려고 하는 광범한 쏘프트웨어개발기업체들에 의하여 실현되고 있다. 

2.12. 기타 쏘프트웨어개발공정개선시도 

쏘프트웨 어 품질 을 개 선하기 위한 다른 시 도는 국제 적 인 규격 화기 구 (ISO) 9000계 렬 
표준에 기초하고 있다. 이 계 렬의 표준은 설계, 개 발, 생산, 설치, 봉사를 비롯한 광범한 
산업 활동들에 리용될수 있는 계 렬화된 5개의 련관된 표준들이다. 즉 ISO 9000이 명백 히 
쏘프트웨 어표준은 아니 다. ISO 9000계 렬안에 서 품질 체 계 를 위한 ISO 9001규격 [ISO 9001, 
198刀은 쏘프트웨 어개 발에 가장 널 리 응용할수 있 는 규격 으로 되 여 있 다. ISO 9001의 보 
편성으로 하여 ISO 는 ISO 9001을 쏘프트웨어에 적용할 때 도움을 주는 특정한 지침 즉 
ISO 9000-3[ISO 9000-3, 1991] 을 출판하였다. 

ISO 9000은 CMM 과 구별해 볼수 있는 많은 특징들을 가지고 있다 [Dawood, 1994]. 
ISO 9000은 순응성 과 리해성 을 담보하기 위하여 설명과 그림 으로써 공정 을 문서 화하는 
데 중심을 두고 있다. 또한 ISO 9(X)0 에 관통되여 있는 원리는 규격의 사항을 준수하는것 
이 질 높은 제품을 담보하지는 않지만 불충분한 질을 가진 제품이 개발될 위험성을 줄인 
다는것이다. ISO 9000은 품질보증체계의 일부분일 따름이다. 또한 요구되는것은 품질에 
대 한 관리 자측의 책 임, 로동자들의 집 중적 인 숙련，련속적 인 품질개 선을 위한 목표의 설 
정과 달성이다. 

ISO 9000계렬규격들은 미국과 일본，카나다, 유럽동맹나라들을 포함하여 60개를 넘 
는 나라들에서 이미 쓰이고 있다. 이것은 실례로 만일 미국의 쏘프트웨어개발기업체가 
유럽의 의뢰 자와 함께 업무를 진행하려 고 하면 미 국의 기 업체 가 우선 ISO 9000의 승인 
자라는것 이 보증되여야 한다는것을 의미하고 있다. 확증된 등록원(검사원)은 회사의 공정 
을 조사하고 그 공정 이 ISO 규격 에 따른다는것을 보증해 야 한다. 

유럽의 대방들을 따라서 점점 더 많은 미국의 기업체들이 ISO 9000에 대한 보증을 
요구하고 있다. 실례로 제너럴 엘렉트리크 플래스리크 디비전 (General Electric Plastic 
Division) 은 1993 년 6 월에 340개의 자동판매 기 가 이 기준에 도달하였다고 주장하였 다 
[Dawood, 1994]. 미행정부가 유럽동맹을 따라 자기 나라에 있는 기업체들과 영업거래를 
하려는 다른 나라의 회사들에 대해서는 ISO 9000승인을 요구하는것 같지는 않다. 그럼에 
도 불구하고 자국내 에서와 그 기 본무역거 래상대들로부터 의 압력은 결국 세 계적범위에 
서 의 ISO 9000승인을 초래할수도 있 다. 

ISO/IEC 15504는 ISO 9(X)0 과 같이 국제적인 공정개선시도이다. 이러한 시도는 이전 
에 는 쏘프트웨 어공정 개 선능력 결정 의 략어 인 SPICE 로 알려 져 있 었 다. 40여개 를 넘 는 나 
라들에 서 SPICE 를 시 도하기 위하여 적 극 노력 하고 있 다. SPICE 는 그것 을 하나의 국제 적 
인 표준으로서 확립하려 는 장기 적 인 목적 과 함께 영 국국방성 (MOD) 에 의하여 시 도되 였 다. 
SPICE 의 첫번째 판본은 1995년에 완성되였으며 1997년 7월에 SPICE 의 시도는 국제규격 
화기구와 국제전기기술의 공동위원회에 의하여 실현되였다. 이러한 리유로 하여 시도의 
이름도 SPICE 로부터 ISO/IEC15504 또는 간단히 15504로 바뀌 여 졌 다. 
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2.13. 쏘프트웨어개발공정개선의 비용과 리득 

쏘프트웨 어공정을 개선하는것 이 수익성을 증가시키 는가? 예비적 인 결과들은 이것 이 
정말로 사실이라는것을 보여 주었다. 실례로 캘리포니아의 풀레톤에 있는 후그스항공기 
의 쏘프트웨 어공학기 술부에 서 는 1987년과 1990년사이에 평 가개 선계 획 에 약 50만딸라를 
소비하였 다 [ Humphrey , Snider and Willis , 1991]. 이 3 년기 간에 후그스항공기 는 앞으로 4준 
위로 지어는 5준위로 개선되리라는 기대를 가지고 성숙준위 2에서 성숙준위 3으로 이행 
하였다. 개발공정이 개선된 결과 후그스항공기는 년간절약액이 200만딸라로 추정되였다. 
이러한 절약은 여러가지 방법으로 축적되게 되였는데 이 방법들에는 감소된 초과시간, 
보다 적은 위 험성, 개선된 종업 원들의 사기 그리 고 쏘프트웨어전문가들의 보다 적은 이 
동들이 포함된다. 

비 교할만한 결과들이 기 타 다른 기 업체들에서 보고되였다. 실례로 레이씨온에 있는 
설 비 디 비 견은 1988년의 1준위 로부터 1993년에 는 3준위 로 올라 갔다. 생 산성 은 두배 로 증 
가되 게 되 였고 개 발공정 개 선노력 에 투자된 비 용에 대 하여 1딸라당 7.7 딸라의 리윤을 얻 
게 되였다. 멜 름베르그는 류사한 성과를 거두었다 [Wohlwend and Rosenbaun , 1993]. 이러 
한 결과로 능력성숙도모형은 여러 나라의 쏘프트웨어산업에서 비교적 널리 적용되고 있 
다. 그림 2-2 는 초기의 CMM 연구에 참가했던 13개의 큰 기업체들에 대한 SEI 보고들로부 
터 뽑은것 이 다 [Herbsleb et al ., 1994]. 


범 주 

범위 

중간값 

자료점의 개수 

쏘프트웨 어 공정 개 선 ( SPI ) 년들 

1-9 

3.5 

24 

쏘프트웨 어 공학자 한사람당 SPI 년간비 용 

490-2, 004 딸라 

1,375 딸라 

5 

년간 생산증가률 

9-67% 

35% 

4 

년간 초기오유발견률 

6-25% 

22% 

3 

년간 시간에 따르는 판매감소률 

15-23% 

19% 

2 

년간 후에 해결된 오유보고서감소률 

10-94% 

39% 

5 

영 업비(절약 / SPI 비용) 

4.0 — 8.8:1 

5.0:1 

5 


그림 2-2. SW _ CMM 쏘프트웨 어개 선자료 [Herbsleb etal .，1994] 

( 《 CMM 지 향쏘프트웨 어 공정 개 선의 리 익 성 : 초기 보고서》에 서 표 2 를 재 작성 한 
특별허가는 카네기멜론종합대학 1994 년판 CMM/SEI-94-TR-013 이 
쏘프트웨 어공학협 회 에서 승인되 였 다. ) 

이 론문에서 인용한 표본은 국방성계약자，군사기구들 그리고 상업쏘프트웨어기업체 
들을 비롯한 넓은 범위의 쏘프트웨어개발자들로 구성되였다. 매개 기업체들은 서로 다른 
방법으로 비용과 생산성과 같은 량적지표들을 측정하고 이러한 량적지표들이 시간이 감 
에 따라 어떻게 변화하는가에 초점을 두고 연구를 진행하였다. 그림에서 보여 준바와 같 
이 생 산성 과 초기결 함발견 이 증가하였 으며 결 함보고서 를 조사하고 발표하는 시 간은 감소 
되 였 다. 그림 2-2 는 또한 쏘프트웨 어개 발공정 개 선에 지 출된 딸라당 절 약이 5 딸라를 중심 
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그림 2-3. 34개의 모토를라 GED 프로젝트의 결과 
(MEASL 는《백만개의 아쌤블리 어원천행》으로 작성되 였다. ) 

[Diaz and Sligo, 1997] (©1997, IEEE.) 

그림 2-3 에서 볼수 있는바와 같이 품질은 성숙준위가 높아 지는데 따라 높아 진다. 
마지 막으로 생 산성 은 시 간당 사람이 작성한 MEASL 로 측정 된 다. 비 밀 보장을 리유로 모 
토롤라는 실제 생 산성 에 대 한 그림 을 공개하지 않았다. 그러 므로 그림 2-3 은 2 준위 프로 
젝트의 생산성에 관련되는 생산성을 반영하고 있다(품질이나 생산성에 대한 그림을 1준 
위프로젝트들에 대해서는 리용할수 없다. 왜냐하면 개발림이 1준위에 있을 때에는 이러 
한 량들을 측정할수 없기 때 문이 다.). 

이 절에서 서술된것과 이 장의 보충부분에서 렬거된것과 갈은 공개된 연구결과들로 
써 세계적으로 더욱더 많은 기업체들이 개발공정개선이 비용에서 효과적이라는것을 깨닫 
고 있다. 

개 발공정 개 선움직 임 의 흥미 있 는 한가지 효과는 쏘프트웨 어개 발공정 시 도와 쏘프트웨 
어공학표준사이의 호상작용이다. 실례로 1995 년에 있은 국제표준화기구는 완전한 쏘프트 
웨어생명주기에 대한 규격으로서 ISO/IEC 12207 을 발표하였다 [ ISO/IEC 12207, 1995]. 3 년 
후에 규격 IEEE/EIA 12207 의 판본이 국제전기 및 전자공학협회 ( IEEE ) 와 전자산업동맹 
( EIA ) 에 의하여 발표되 였다. 이 판본은 많은 쏘프트웨어의 《 가장 좋은 실천》을 병 합하 
였다. IEEE/EIA 의 승인을 받기 위하여서는 기업체가 CMM 능력준위 3 근방에 있어야 한다 
[Ferguson and Sheard , 1998]. 또한 ISO 9000-3 은 지금 ISO/IEC 12207 의 부분적 인것들을 병 


으로 4 딸라부터 8.8 딸라범위 에 있다는것을 보여 주고 있다. 연구를 진행한 13 개 기 업 체들 
은 SEI SM-CMM 은 아닌 여 러 가지 개 발공정개선사업 에 적극 참가하였다. 

모토를라정 부전자디 비 젼 ( GED ) 은 1992 년부터 SEI 의 쏘프트웨 어 개 발공정 개 선계 획 에 
적 극적 으로 개 입하였 다 [Diaz and Sligo , 1997]. 그림 2_3 은 GED 프로젝 트를 보여 주고 있 
는데 그것은 매개 프로젝트를 개발한 그롭의 성숙준위에 따라 분류되여 있다. 그림에서 
볼수 있는바와 같이 련관된 기간(즉 1992 년전에 완성된 기준선에 상대적인 프로젝트의 
기간)은 성숙준위의 증가와 함께 감소되였다. 품질은 백만개의 등가적 인 아쌤블리 어원천 
행 ( MEASL ) 당 오유에 의하여 측정되였다. 즉 서로다른 언어로 실현한 프로젝트들을 비 
교할수 있도록 원천코드의 행수는 등가적 인 아쌤 블리 어코드의 행수로 변환된다 [ Jones , 
1996]. 


기간에 대한 개발기간에 발견된 상대적인 

CMM 준위 프로젝트수 상대적 인 감소량 MEASL 당 오유 생산성 



위 위 위 위 위 

즈71 추ᄂ 주ᄂ 주ᄂ 준 
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합하고 있다. 이것 은 쏘프트웨 어 공학규격 화기구와 쏘프트웨 어 개 발공정 개선시도사이 에서 
벌어 지는 이러한 호상작용을 반드시 보다 더 좋은 쏘프트웨어개발공정에로 이끌어 갈것 
이다. 


o 야 

-L 上 —I 

몇개의 예비적인 정의를 한 다음 (2.1) 요구사항확정단계 (2.2) 로부터 페기 (2.8) 에 이르 
는 쏘프트웨어공정의 매 단계를 서술하였다. 매 단계들과 련관된 문제들에 특별한 주의 
를 돌렸다. 시험은 모든 쏘프트웨어생산활동과 병렬로 수행되여야 하기때문에 개별적인 
단계로 고찰하지 않았다. 매 생명주기단계 에서 진행되는 시험에 대 한 설명은 2.2.1 부터 
2.7.1 까지에서 주었다. 류사하게 문서작성도 2.2.2 에서 2.7.2 까지에서 서술한바와 같이 쏘 
프트웨어제품개 발의 고유한 부분이 다. 매 개 별적 인 쏘프트웨 어생 명주기와 련관된 문제들 
외 에 쏘프트웨 어 제 품개 발에 서 의 본질적 인 난점 들과 관련 한 브룩스의 견해 도 서 술하였 다 
(2.9). 브룩스가 고찰한 쏘프트웨어의 본질적 인 네 가지 측면에서의 난점 은 복잡성，순응성 , 
가변성，비 가시성인데 2.9.1 부터 2.9.4 에 서 서 술하고 론의하였 다. 브룩스의 견해 는 2.9.5 에 
서 분석되였다. 

이 장의 마지 막부분은 쏘프트웨 어개 발공정 개 선 이 다 (2 JO ). CMMI (2.1) 와 ISO 9000과 
ISO/IEC 15504(2.12) 를 비 롯한 국제 적 인 쏘프트웨 어 개 선시 도들을 상세 하게 주었 다. 쏘프 
트웨 어 개 발공정 개 선 에 대 한 비 용의 효과성 은 2. 13에 서 론의 하였 다. 

보 충 

계1장의 보충에 있는 검토에 관한 기사들 즉 문헌 [ Brooks , 1975; Boehm , 1976; DeMarco 
and Lister , 1989; Wasserman , 1996; and Ebert , Matsubara , Pezze , and Bertelsen , 199 기은 또 
한 쏘프트웨 어제품개 발과 관련한 문제들을 강조하고 있다. 

생명주기의 매 단계에서의 시험과 관련하여 하나의 좋은 참고서는 문헌 [ Beizer , 
1990] 이 다. 보다 더 자세한 참고서 는 제 6장에 서 주었 고 6장의 보충부분의 마감에 주었 다. 
여기에서 서술한것과 갈은 개요는 브룩스의 기사《은총탄은 없다.》를 공정하게 평가할 
수 없다. 이 기사는 원래의 문헌 [ Brooks , 1986] 에서 읽어야 한다. 브룩스의 기사에 대한 
많은 반향들가운데서 목스는 문헌 [ Cox , 1990] 에서 사실상 은총탄이 존재 한다고 제기하 
였다. 즉 객체 의 재 리용이 있 다고 제 기하였 다 (8 장에 서 서 술하였 다.). 문헌 [ Harel ，1992] 에 
서 서 술한 견해 는 비 록 브룩스의 견해 와 거 의 일 치하지 만 보다 새 로운 기 술의 출현과 함 
께 전망은 브룩스의 견해 에 서보다는 나쁘지 않다. 문헌 [ Mays , 1994] 는 은총탄문제 에 대 
한 다른 흥미 있는 견해 를 주고 있 다. 쏘프트웨어 의 복잡성 에 대 한 론쟁 은 IEEE 
Computer 1997년 7월호의 여 러 기사들에서 찾아 볼수 있다. 

원래 의 SEI 능력 성 숙도모형 에 대 한 상세한 설명 은 문헌 [ Humphrey , 1989] 에 서 주고 
있다. 능력성숙도모형통합이 문헌 [ SEI , 200이에 서술되여 있다. 문헌 [ Humphrey , 1996] 은 
개인쏘프트웨어개발공정 ( PSP ) 를 서술하고 있다. 즉 PSP 를 적용한 결과는 문헌 [Ferguson 
et al „ 199刀에 있다. PSP 와 관련한 일부 잠재적 인 문제들은 문헌 [Johnson and Disney , 
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1998] 에 서 론의 하였 다. PSP 와 림 쏘프트웨 어 개 발공정 (TSP) 는 [Humphrey, 1999] 에 서 서 술되 
였 다. CMM 의 성 공은 문헌 [Hicks and Card, 1994] 에 서 술되 여 있 으며 평 가공정 에 대 한 
비평은 문헌 [Bollinger and McGowan, 1991] 에 있다. IEEE Software 1993년 7월호에는 
CMM 에 관한 많은 론문들이 포함되 여 있다. IEEE Software 2000년 7월/8월호에는 쏘프트 
웨어개발공정완성에 관한 네개의 론문이 있으며 IEEE Software 2000년 11월/12월호에는 
PSP 에 대한 5개의 론문이 있다. 

1987년과 1991 년사이 에 있은 SEI 쏘프트웨 어 개 발공정 평 가에 대 한 개 관은 문헌 [Kitson 
and Masters, 1993] 에 주었다. 즉 보다 새로운 결과는 문헌 [Herbsleb et al„ 199기에서 통합 
되 였 다. 많은 기 사들은 SEI 개 발공정 개 선계 획 을 도입한 특정 한 회 사들의 견지 에 서 산업 적 경 
험에 대하여 서술하고 있다. 즉 전형적인 실례는 멜렘베르그 [Wohlwend and Rosenbaum, 
1993] 와 레이씨온 [Haley, 1996] 에서 찾아 볼수 있다. 쏘프트웨 어산업 에 대한 SEI 의 충격은 
문헌 [Saiedian and Kuzara, 1995] 와 [Brodman and Johnson, 1996] 에서 론의되 였다. CMM 에 
대하여 흥미 있는 견해는 문헌 [Bamberger, 199刀에서 보여 주고 있다. 

문헌 [Bamford and Deibler, 1993b] 는 ISO 9000 과 CMM 에 대 하여 상세 한 비 교를 주었 
다. 즉 문헌 [Bamford and Deibler, 1993a] 에 서 개 관을 주었 다. 문헌 [Paulk, 1995] 에서 는 또 
다른 하나의 비교를 주었다. 아일랜드의 코르크에 있는 모토를라그룹이 어떻게 되여 성 
숙준위 4로 발전하였는가 하는 방법을 문헌 [Fitzgerald and O'Kane, 1999] 에서 주었다. 
CMM 에 대한 정보가 풍부하게 지적되여 있는것은 SEI CMM 의 web 싸이트가 www.sei.cmu. 
edu 이 다. ISO/IEC 15504(SPICE) 홈페 지는 www.sei.cmu.edu/technology/process/spice/ 이 다. 

Proceedings of ACM 1997년 6월 호에 는 쏘프트웨 어 의 품질 과 CMM 에 관한 많은 론문 
들이 있다. 즉 문헌 [Herbsleb et al„ 199刀은 특별히 흥미 있다. 쏘프트웨어공학연구소의 
또 하나의 개 발공정 개선계 획은 문헌 [Basili et al„ 1995] 에 서술되 여 있다. 문헌 [Fuggetta 
and Picco, 1994] 은 공정개선에 관한 주석을 단 참고문헌을 주었다. CMM 과 IEEE/EIA 
12207사이의 비교를 문헌 [Ferguson and Sheard, 1998] 에 주었다. 더우기 CMM 과 Six 
Sigma (개발공정개선을 위한 또 하나의 방법)는 [Card, 2000] 에서 찾아 볼수 있 다. 공정 평 
가에서의 일부 결함들을 문헌 [Fayad and Laitinen, 199기에 주었다. 

문 제 

2.1. 의뢰자, 개발자，사용자들이 다 갈은 사람인 상황을 서술하시오. 

2.2. 의뢰자，개발자，사용자들이 다 갈은 사람인 경우에 무슨 문제가 발생하는가? 이 
문제들을 어떻게 해결할수 있는가? 

2.3. 의뢰자，개발자, 사용자가 다 같은 사람이면 어떤 잠재적인 우월성이 생기게 되 
는가? 

2.4. 요구사항확정단계 와 명세작성단계 를 생 각해 보자. 그것 들을 따로 개 별적 으로 취 


이 책 에서 지적한 URL 들은 집 필시 에는 정확한것들이 였다. 그러 나 web 주소는 아주 빈 
번히 변화되고 있다. 이렇게 되면 독자들은 탐색기구를 리용하여 새로운 URL 을 찾아야 한다. 
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급하는것보다 하나의 단계로 두 공정을 결합하는것이 더 의미가 있는가? 

2.5. 쏘프트웨 어생명주기의 매 단계들에서 진행되 여 야 할 문서 작성을 렬거하시오. 

2.6. 다른 개발단계에서보다 통합단계기간에 그이상의 시험이 진행된다. 이 단계를 
두개 의 개 별적 인 단계 로 분할하는것 이 더 좋겠는가? 즉 하나는 비 시험 측면을 통합하고 
다른 하나는 모든 시험을 통합한다는것이다. 

2.7. 유지 정 비단계 는 쏘프트웨 어 제 품개 발에 서 가장 중요한 단계 이 며 실 현하는데 서 는 
가장 어 려 운 단계 이 다. 그럼 에 도 불구하고 그것 은 많은 쏘프트웨어 전문가들에 게 서 차요 
시되 고 유지정 비하는 사람들은 다른 개 발자들보다 흔히 적은 보수를 받고 있다. 이것 이 
합리적 이 라고 생각하는가? 아니 라면 그것을 변경 하기 위하여 어떻게 시도하겠는가? 

2.8. 2.8 에서 언급한바와 같이 왜 진실한 폐기가 보기 드문 일이라고 하는가? 

2.9. 엘 메르쏘프트웨 어 회 사에 서 화재 로 인 하여 어 떤 프로젝 트에 대 한 모든 문서 가 배 
포되기전에 소각되였다. 결과 문서작성의 결핍으로 하여 어떤 충격이 있게 되는가? 

2.10. 브룩스는 복잡성，순응성, 가변성，비 가시 성 으로 하여 쏘프트웨어 제 품이 실 질적 
으로 어 렵 다고 하였 다. 법 률이 나 의 학, 신학과 공학을 비롯한 인간활동의 다른 령역 들도 
또한 어렵다. 복잡성, 순응성, 가변성, 비가시성 이것은 이러한 매 령역들에 어느 정도 영 
향을 주는가? 

2.11. 브룩스는 쏘프트웨 어기 술에서 의 가장 중요한 돌파선용 고급언어 와 시 분할，쏘 
프트웨어개 발환경이 라고 고찰하였 다. 가장 주요한 쏘프트웨 어돌파선 이 무엇 이 라고 생 각 
하는가? 대 답과 함께 그 리유를 설 명 하시 오. 

2.12. 교원 이 배 포한 쏘프트웨어 의 상세한 흐름도표를 그리 시 오. 그것 을 리해 하기 가 
쉬 운가? 하나의 롱을 차지하는 모든 릉들을 제 거 함으로써 흐름도표를 평 면 으로 되 도록 
하시 오. 그 흐름도표가 더 리해 하기 쉬 운가? 원래 의 기 능이 얼 마나 류실되 였는가? 결과적 
인 평 면형흐름도표를 원래 의 프로그람작성언어 로 반대 로 번역하여 실행시키시 오. 쏘프트 
웨어는《볼수 없으며 볼수 없게 한다.》고 한 브룩스의 진술에 동의 하는가? 

2.13. 회 사가 성 숙준위 1 에 있 기 때 문에 파산직 전 에 이 른 회 사의 쏘프트웨 어 개 발자들 
을 방금 받아 들였다. 그 회사를 유익하게 되살려 회귀시키 려면 처 음에 무엇을 해 야 하 
는가? 

2.14. (과정 안상 목표) 부록 1에 있는 브로드렌즈지역 아동병 원쏘프트웨 어제품에 대 하 
여 쏘프트웨 어제품개 발에서 본질적 인 4개의 문제(복잡성，순응성，가변성，비 가시성)이 어 
떻 게 영 향을 주는가를 론의하시 오. 

2.15. (쏘프트웨 어공학독본) 교원은 문헌 [Johnson and Disney , 1998] 의 복제본을 배 포 
하여 줄것 이 다. 만일 쏘프트웨 어 회 사를 담당하게 된 다면 개 인쏘프트웨 어개 발을 도입하겠 
는가? 
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제 3 장. 쏘프트웨어생명주기모형 


쏘프트웨어생산은 보통 애매한 개념들로 시작된다. 즉《만일 콤퓨터가 방사능준위 
에 대한 그라프를 그려 낼수 있다면 그것은 좋은것이 못된다.》또는《만일 이 회사가 
매일 기초로 되는 현금의 흐름에 대한 정확한 표상을 가지고 있지 않다면 우리는 여섯달 
만에 빚을 갚을수 없게 된다.》또는 지어 《우리가 이러한 새로운 류형의 표처리프로그 
탐을 개발하여 시장에 내가면 백만딸라를 벌게 될것이다.》라는 등의 애매한 개념들로 
시작된다. 일단 제품에 대한 요구가 설정되면 제품은 일련의 개발단계를 거치게 된다. 대 
표적으로 제품은 명세작성되고 설계되며 실현되게 된다. 만일 의뢰자가 만족하게 되면 
제품은 설치되여 동작하는 기간에 유지정비된다. 만일 제품이 이제 더는 쓸모가 없게 되 
면 그것은 폐기된다. 제품이 발전 하게 되는 이러한 단계를 생명주기 모형여/ e - cyc/e model ) 
이라고 부른다. 

매 제품의 생 명주기경 력은 서 로 다르다. 일부 제품들은 여 러해동안 개 념적 인 단계 에 
머물러 있게 된다. 왜냐하면 현재의 하드웨어가 그 제품이 충분히 실행될수 있을 정도로 
빠르지 못하거나 효률적인 알고리듬이 개발되기전에 기본적인 연구가 진행되여야 하기때 
문이다. 일부 제품들은 빨리 설계되고 실현된 다음 사용자들의 요구에 맞게 수정되도록 
하는 유지정 비단계에서 여 러 해 걸리게 된다. 또한 일부 제품들은 설계되 고 실현되고 유 
지 정 비 된 다. 기 본적 인 유지 정 비 를 몇 해 진행 한 다음에 는 현재 의 판본을 다시 보수하려 고 
하는것보다 완전히 새로운 제품을 개 발하는것 이 더 값이 눅게 된다. 

이 장에서는 여러가지 서로 다른 생명주기모형들에 대하여 서술한다. 가장 널리 리 
용되 는 두가지 모형 은 폭포모형 과 신속원형작성모형 이 다. 이 밖에 라선모형 이 지 금에 와 
서 상당한 주목을 끌고 있 다. 이 세 모형 들의 우점 과 약점 을 밝히 기 위하여 증식 모형 과 
동기 및 안정 화모형 그리 고 매우 충분하지 못한 구성 및 수정모형을 비롯한 기 타 생 명주 
기모형들도 고찰한다. 


3. 1 . 구성 및 수정모령 

많은 제품들이 구성 및 수정모형을 리용하여 개발된다는것은 유감스러운 일이 다. 그 
제 품은 명세서도 없 이 구성 되거나 설 계 에 진 입 하게 된 다. 대 신 에 개 발자들은 의뢰자들을 
만족시키기 위하여 필요한 회수만큼 재작업하게 되는 어떤 제품을 개발하게 된다. 이러 
한 방법을 그림 3-1 에 보여 주었다. 

비 록 이 연구방법 이 100 또는 200개행 의 크기 를 가진 짧은 프로그람을 작성하는 련 
습에서는 잘 동작할수 있다고 하더 라도 구성 및 수정모형 은 임의 의 합당한 크기 를 가진 
제품에 대 해서는 전혀 충분하지 않다. 만일 그에 대 한 변경 이 요구사항확정과 명세작성 
또는 설계 단계 에 서 이 루어 지 면 쏘프트웨 어 제품을 변경 시키 는데 드는 비 용은 상대 적 으로 
작아 지지만 제품이 다 코드작성된 다음에 변경이 이루어 지면 비용은 매우 커지게 되고 
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또는 이 미 유지 정 비단계 에 들어 섰 다면 정 황은 더 불리해 진 다는것 을 그림 1-5 에 서 보여 
주고 있 다. 결 국 구성 및 수정방법 에 드는 비 용은 사실 상 적 당하게 명 세작성 되 고 주의 깊 
게 설계된 제품의 비용보다도 훨씬 더 크게 된다. 이밖에 제품에 대한 유지정비는 명세 
서나 설계문서가 없으면 매우 곤난하게 되며 회귀오유가 일어 날수 있는 기회는 상당히 
더 커지게 된다. 



그림 3-1. 구성 및 수정모형 

구성 및 수정모형대신 제품개발을 시작하기전에 전면적인 방식계획이나 생명주기 
모형 이 선택 되 는것 은 필수적 이 다. 생 명 주기모형(때 때 로 모형 으로 생 략한다.)은 요구사항 
확정과 명세작성，설계，실현，통합과 유지정 비와 같은 쏘프트웨 어개 발공정의 여 러단계 
들을 그것 들이 진행 되 는 순서 에 따라 규정 하고 있다. 일 단 모든 당사자들이 생 명 주기 
에 동의하면 제 품의 개 발을 시 작할수 있게 된 다. 

1980년대 초까지 폭포모형 은 널 리 리용되 여 온 유일한 생 명 주기모형이 였 다. 이 모형 
에 대하여 이제 상세히 설명하기로 한다. 


3. 2. 폭 포 모 형 

폭포모형은 로이스 [ Royce ， 197이가 처음으로 내놓았다. 이 모형의 한가지 류형을 그 
림 3-2 에 제 시한다. 

우선 의 뢰 자와 쏘프트웨 어품질보증 ( SQA ) 그룹에 의해서 요구사항이 결정 되 고 검 사된 
다. 그다음 제품에 대한 명세서가 작성된다. 즉 제품이 무엇을 하여야 하는가를 서술하는 
문서 가 작성된다. 명세서는 SQA 그롭에 의해서 검사되 고 의 뢰 자들에 보여 주게 된다. 일 
단 의뢰 자가 명세서 에 수표하면 다음단계에서 는 쏘프트웨어 를 개 발하기 위한 상세한 시 
간표로 되 는 쏘프트웨 어관리계 획 이 작성된다. 이 계 획도 역 시 SQA 그룹에 의하여 검 사된 
다. 의 뢰 자가 개 발자의 개 발기 간과 그 제 품에 대 한 비 용타산에 찬성하면 설 계 단계 가 시 


80 






계단계에서는 때때로 명세서에 있는 오유가 명백해 지게 된다. 명세서는 불완전 
a 고(제품에 대한 일부 특성이 빠져 있다.) 모순적일수도 있고(명세서에서 둘이상 
•이 량립될수 없는 방법으로 제품을 정의한다.) 또는 애매할수도 있다(명세서가 
•의 가능한 해석을 포함하고 있다.). 불완전성과 모순성, 애매성이 존재하는것은 
어개발공정을 거치기전에 명세서에 대한 교열을 진행할것을 요구한다. 다시 그 
참고하면 왼쪽의 설계 단계통으로부터 명세작성단계통으로 거꾸로 그어 진 화살 
■합고리를 이룬다. 만일 개발자들이 설계단계에서 명세서를 교열하면 쏘 프트웨 
•정은 이러한 반결합고리를 따라 진행되게 된다. 의뢰자의 허가를 받고 명세서에 




필요한 변경들이 진행되며 계획작성과 설계문서도 이러한 변경을 병합하도록 조정된다. 
개발자들이 최종적으로 만족하게 되면 설계문서는 실현을 위 하여 프로그람작성자들에게 
넘겨 진다. 설계단계에서의 결함은 실현단계에도 반영된다. 어떤 실시간체계에 대한 설계 
는 실현될 때 아주 느리다고 인정될수 있다. 이러한 설계상결함에 대한 실례는 대부분의 
콤파일러가 어떤 배렬 b 의 요소들을 행 우선순서로 즉 b ( l . l ), b ( l , 2), b ( l , 3), •••, b ( l , 17), 
b (2, 1), b (2, 2), b (2, 3), •••, b (2, 7) 으로 기 억 하기 위 한 코드를 발생 한다는 사실로부터 생 
겨 난다. 하나의 200 X 200 배렬 b 가 블로크의 한 행으로 디스크에 기억된다. 즉 200개의 
단어를 가진 행 이 read 명 령 이 실행될 때 마다 주기 억의 완충기 에 로 읽혀 진다고 가정 하자. 
만일 배렬이 한 행씩 읽혀 진다면 그때는 모든 40,000개의 원소가 모두 읽혀 지도록 정확 
히 200개 의 블로크가 디 스크로부터 주기억 에 전송되 여 야 한다. 첫 read 명 령 문이 첫 행 을 
완충기에 넣 어 지도록 하며 첫 200개의 read 명령문은 완충기의 내용을 리용하게 된다. 그 
러 면 2()1 번째 원소가 읽 어 질 때 에만 디스크로부터 주기억 에 전송되 여 야 할 두번째 블로 
크가 요구되게 된다. 그러나 만일 제품이 배럴을 한 렬씩 읽는다면 서로 다른 행들을 호 
출하기 때 문에 매 read 명 령 문에 대 하여 새 로운 블로크가 전송되 여 야 한다. 이 리 하여 배 렬 
이 행 우선순서로 읽혀 질 때의 200개 블로크대신에 40,000개 블로크전송이 요구되며 제품 
의 그 부분에 대하여 입출력시간은 200배나 더 길어 지게 된다. 이러한 류형의 설계결함 
은 림에서 쏘프트웨 어개 발을 계 속할수 있게 되 기 전에 퇴 치 되 여 야 한다. 실현단계 에서 그 
러한 반결합고리를 가진 폭포모형은 설계문서와 명세서, 필요하다면 요구사항에 대하여 
변경이 진행되도록 한다. 

모둘은 실현되 고 문서 화되 고 통합되 여 하나의 완전한 제 품을 형 성하게 된 다(실 천적 
으로 실현과 통합단계는 보통 병렬로 수행된다. 1.5 에서 서술한바와 같이 매 모둘은 그것 
이 실현되 고 시 험되 자마자 통합된다.). 통합단계 에서 는 명세서 와 설계문서 에 대 한 수정 에 
앞서 코드를 거 꾸로 추적하여 변경 을 진행하는것 이 필요하다. 

폭포모형과 관련한 중요한 점은 그 단계에 대한 문서작성이 완성되고 그 단계에서의 
제 품이 SQA 그룹에 의해서 승인될 때 까지 그 어 느 단계 도 완성 되 지 않는다는것 이 다. 이 
것은 변경을 하여야만 된다. 즉 만일 어떤 앞단계에서의 제품이 그다음에 오는 반결합고 
리에 따라서 변경되여야 한다면 그 앞선 단계는 그 단계에 대한 문서가 변경되고 SQA 그 
룹에 의해서 그 변경 이 검사될 때 에만 완성될수 있다고 간주된다. 개 발자들이 제품이 성 
과적 으로 완성되 였 다고 생 각되 게 되 면 제 품은 인수시 험 을 받기 위하여 의 뢰 자에 게 넘 겨 
진다. 이 단계에서 배포물들에는 계약에 렬거된 사용자지도서와 기타 문서들이 포함된다. 
제품이 실지로 그 명세서를 만족시킨다고 의뢰자들이 인정할 때 그 제품은 의뢰자에게 
넘겨 져서 의뢰자의 콤퓨터에 설치된다. 일단 의뢰자가 제품을 인수하면 잔류오유들을 
제 거하거 나 기 타 방법 으로 제 품을 확장하려 고 하는 그러한 모든 변경 들이 유지 정 비 를 이 
룬다. 그림 3-2 에서 볼수 있는바와 같이 유지정비는 바로 실현단계의 변경뿐아니라 설계 
단계 와 명세작성단계 에서의 변경 도 요구하게 된다. 이 밖에 확장은 요구사항확정단계 에서 
의 변경 에 의하여 유발된다. 이 것은 명세서 와 설계문서, 코드에서의 변경 을 통하여 차례 
로 실현된다. 폭포모형은 동적모형이며 반결합고리는 이러한 동적구조에서 중요한 역할 
을 한다. 또한 문서 작성 이 코드 그자체 와 마찬가지 로 조심히 유지정 비되 고 매 단계 에서 
의 제품이 다음단계가 개시되기전에 주의 깊게 검사되는것이 사활적이다. 폭포모형이 리 


82 





용되여 폭 넓고 다양한 여러가지 제품들에서 큰 성과를 거두었다. 그러나 실패도 있었다. 
어떤 프로젝트에 대한 폭포모형의 리용여부를 결정하기 위해서는 그것의 약점과 우점을 
리해하는것이 필요하다. 


3. 2. 1 . 폭포모형의 분석 

폭포모형은 학문적성격이 강한 방법 즉 매 단계에서 문서작성이 진행되고 매 단계에 
서의 모든 제품들이(문서 작성 을 포함) SQA 에 의해서 주의 깊게 검 사되 여 야 한다고 하는 
요구를 비 롯하여 많은 우월 성 을 가지 고 있다. 매 단계 를 끝내 는 리정 표에 대 한 한가지 
본질적인 측면은 그 단계에 대하여 명시된 모든 문서들을 비롯하여 그 단계의 모든 제품 
들이 SQA 그룹에 의하여 증명 되 여 야 한다는것 이 다. 폭포모형 의 매 단계 에 서 고유한것 은 
시험이다. 시험단계는 제품이 구성되였을 때에만 진행되는 분리된 단계가 아니며 매 단 
계의 마감에만 진행되는것은 아니다. 대신에 제2장에서 언급한바와 같이 시험은 쏘프트 
웨어개발공정전반에 걸쳐 계속 진행되여야 한다. 특히 요구사항확정이 진행되는 동안 그 
것들은 확증되여야 하며 설계문서는 물론 명세서와 쏘프트웨어관리계획도 확증되여야 한 
다. 코드는 여 러 가지 방법 으로 시 험되 여 야 한다. 유지정 비단계 에서는 변경된 제품판본이 
여전히 그이전 제품판본이 수행하던것을 할수 있으며 즉 여전히 그것이 정확하게 수행된 
다는것(회귀시 험)뿐아니 라 의 뢰 자에 의해서 강요된 그 어 떤 새 로운 요구를 전적 으로 만 
족시킨다는것을 담보해야 한다. 

명세서 와 설계문서 , 코드문서 와 그리 고 자료기 지 도서，사용자지도서 , 조작지도서 와 
같은 기 타 문서 들은 제 품을 유지 정 비 하기 위한 필 수적 인 수단으로 된 다. 제1장에 서 언급 
한바와 같이 쏘프트웨어개발예산의 평균 67%는 유지정비에 들며 이러한 문서조항들로써 
폭포모형을 지지하면 이러한 유지정비가 더 쉽게 된다. 앞부분에서 언급한바와 같이 쏘 
프트웨어생산에 대한 그러한 질서정연한 방법은 유지정비단계에서 계속된다. 매개의 변 
경 은 련관된 문서 에 반영 되 여 야 한다. 폭포모형 에서의 많은 성 과들은 문서구동모형 으로 
서의 그것의 본질에 기인된다. 

그러 나 폭포모형 이 문서구동이라는 사실은 또한 불리한 경 우도 있을수 있다. 이것 을 
보기 위하여 다음 두개 의 약간 기 묘한 대 본에 대 하여 고찰해 보자. 우선 죠아와 제 인 죤 
슨은 집 을 지 으려 고 결심한다. 그들은 건축설계가와 의논한다. 건축설계가는 그들에 게 설 
계안(스케 치)과 계 획 그리 고 모형 을 보여 줄 대 신에 고급한 기 술용어 로 집 을 묘사한 20 
페지 나 되 는 빼 곡히 타자한 간단한 문서 들을 준다. 지 어 죠아와 제 인이 사전 건축설계경 
험 이 없고 문서 를 힘겹게 리해한다고 할지 라도 그들은 그 문서 에 열정 적 으로 서 명을 하 
고 다음과 같이 말한다.《곧바로 가서 집을 짓자.》다른 대본은 다음과 같다. 마크 마 
베리는 우편주문으로 옷을 산다. 회사는 마크에게 옷도안과 입을만한 옷들의 원형을 우 
편으로 보낼 대 신 그 제 품에 대 하여 서 면작성한 재 단과 천에 대 한 사항을 보낸다. 마크 
는 작성된 사항에 기초해서 독단적으로 옷을 주문한다. 

우의 두 대 본은 아주 다르다. 그럼 에 도 불구하고 그것 들은 폭포모형 을 리용하여 
쏘프트웨어 들을 개 발하는 방법 을 정 확히 특징 짓 고 있다. 개 발공정 은 명 세작성 으로부 
터 시 작된다. 일반적으로 명세서들은 길고 상세하며 솔직히 말하여 읽기 가 지루하다. 
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의뢰자는 보통 쏘프트웨어명세서를 리해는데서 경험이 없다. 이러한 난점은 명세서가 
보통 의뢰자에게 익숙되지 못한 문체로 씌여 졌기때문에 혼돈된다는것이다. 명세서가 
Z 와 같은 형 식 적 명 세 작성 언 에 Spivey , 1992] 로 작성 될 때 난관은 더 욱 커 지 게 된 다 
(11.8). 그럼 에 도 불구하고 의 뢰 자는 적 당히 리해했든 못했든 명세서 에 수표하고 전진 
한다. 다만 부분적으로나마 리해되게 작성된 사항으로부터 집을 세우자고 계약한 죠아 
와 튼슨 그리 고 다만 부분적 으로 리 해 한 명세 서 에 의하여 서 술된 쏘프트웨어 제품을 
승인한 의뢰자들사이에는 많은 측면에서 차이가 거의 없다. 마크 마베리와 그의 우편 
주문옷은 아주 기묘하지만 그것은 폭포모형이 쏘프트웨어생산에 리용될 때 무슨 일이 벌 
어 지 겠는가 하는것 을 명 백하게 하여 준다. 의 뢰 자가 동작하고 있는 제 품을 처 음으로 보 
게 되는 때는 전체 제품이 코드작성된 이후뿐이다. 쏘프트웨어개발자들이 《내 알기에는 
이것 이 내 가 요청한것 이지 만 사실은 내 가 바라는것 이 아니 다.》라는 문장을 무서 워 하면 
서 살고 있다는것은 좀 이상하다. 

무엇 이 잘못되 였 는가? 의 뢰 자들이 명 세 서 에 서 술된대 로 제 품을 리 해 하는 방법 과 실 
제 의 제 품을 리해하는 방법사이 에 는 중요한 차이 가 있 다. 명세 서 는 종이우에 존재할뿐 
이 다. 따라서 의 뢰 자는 그 제 품자체 가 무엇 과 같은가를 실 지 리해할수 없 다. 작성 된 명 세 
서에 크게 의존하는 폭포모형은 의뢰자의 실제요구를 단순히 충족시킬수 없는 제품구성 
에 로 이 끌어 갈수 있 다. 공정 하게 말하면 바로 건축설 계 가들이 모형 이 나 설 계초안, 계 획 
들을 제 공함으로써 의 뢰 자들로 하여 금 무엇 을 건설하게 되 는가를 리해할수 있도록 하는 
것 과 마찬가지 로 쏘프트웨 어공학자들도 의 뢰 자와 통신하기 위하여 자료흐름도 (11.3.1) 와 
갈은 도형적인 기법을 리용할수 있다는것이 지적되여야 한다. 문제는 이러한 도형적인 
수단으로 완성된 제품이 어떻게 동작하는가를 서술하지 않는다는데 있다. 실례로 흐름도 
(생산에 대 한 도식적 인 서술)와 동작하는 제품 그자체사이 에는 중요한 차이가 있다. 시험 
되여야 할 다음 생명주기모형 즉 신속원형작성모형의 우점은 그것이 의뢰자들의 실제요 
구에 맞는다는것을 담보할수 있도록 해준다는것이다. 

3. 3. 신속원형작성모령 

신속원형 ( ra ; 治//? rato 次 pe ) 은 제품의 부분모임과 기능상 등가인 작업모형이다. 실례로 
만일 목적 하는 제 품이 수입 계 산이 나 지 불계 산, 창고를 관리 하는것 이 라면 신속원형 이 자 
료포착을 위한 화면조종을 진행 하고 보고서 를 인쇄하는 제 품으로 구성 될수 있지 만 파일 
갱 신과 오유조종을 하지 못하는 그러한 제 품으로 구성 될 수 있다. 용액 의 효소농도를 결 
정 하는것을 목적 으로 하는 제품의 신속원형은 계산을 진행 하고 해 답을 현시하는것 이지 만 
입력자료에 대한 그어떤 타당성이나 합리성검사는 하지 않는다. 그림 3-3 에 제시한 신 
속원형작성생 명 주기모형 에 서 첫 걸 음은 신속원형 을 작성 하고 의 뢰 자와 장래 의 사용자들 
이 신속원형 을 리용하여 대 화하면서 실 험하게 하는것 이 다. 일 단 의 뢰 자들이 신속원형 이 
대 부분의 실제 요구를 실지 로 만족시 킨다는것 을 확인하면 개 발자들은 제품이 의 뢰 자들의 
실제 요구를 만족시 킨다는 일 련의 담보를 가지 고 명세서 를 작성할수 있다. 신속원형작성 
을 진행하면서 쏘프트웨 어개 발공정 은 그림 3-3 과 같이 계 속 진행 된다. 
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속원형작성모형의 중요한 우점은 제품개발이 본질에 있어서 신속원형작성 
품에 이르기까지 선형으로 진행된다는것이다. 즉 폭포모형(그림 3-2) 의 빈 
i 속원형작성모형에서 필요 없을것 같다. 이에 대해서는 여러가지 리유가 
A 발림성 원들은 명세서 를 작성 하기 위하여 신속원형 을 리용한다. 동작하나 
나뢰자들과의 대 화를 통하여 타당성 이 증명되 기때 문에 결과적 인 명세서 가 
기 대하는것 은 옳다. 둘째 로 설 계 단계 를 고찰하자. 지 어 신속원형 이(아주 
작성되 였 다고 하더 라도 설 계 림 은 그것 을 리해할수 있 다. 즉 최 악의 경 우 





다음에는 실현단계가 진행된다. 폭포모형에서 설계의 실현은 때때로 소소하게 제기 
되 는 설계 상오유와 맞다들게 된다. 신속원형 작성 모형 에 서 초보적 으로 동작하는 모형 이 
이미 작성되였다는 사실은 설계기간에 또는 실현된 다음에 수정에 대한 요구를 줄이게 
한다. 원형은 비록 그것이 완전한 목표제품에 대한 부분적 인 기능만을 반영할수 있다고 
하더라도 설계림에 일련의 견해을 준다. 일단 의뢰자가 제품을 인수하고 설치하면 유지 
정 비 가 시 작된 다. 진행 될 유지 정 비 에 의 존하여 요구사항확정 단계, 명 세 작성 단계, 설 계 단 
계이든가 실현단계에로 순환이 다시 들어 갈수 있다. 

신속원형작성의 본질적 인 측면은 단어 《신속》에서 구체화된다. 개발자들은 쏘프트 
웨어개발공정을 다그칠수 있게 될수록 신속하게 원형을 작성하려고 시도한다. 결국 신속 
원형의 유일한 리용목적은 의뢰자의 실제요구가 무엇인가를 결정하는것이 다. 즉 일단 이 
것이 결정되면 신속원형실현은 무시되지만 엄은 교훈은 남아서 그이후의 개발단계들에서 
의연히 리용되게 된다. 이러한 리유로 하여 신속원형의 내부구조는 상관이 없다. 

중요한것은 바로 원형을 신속하게 작성하고 의뢰자들의 요구를 반영하여 신속하게 
변경되도록 하는것이다. 그러므로 속도가 필수적이다. 

3. 3. 1. 폭포모형과 신속원형작성모형의 ■합 

폭포모형은 성공적임에도 불구하고 의뢰자들에게 배포된것은 실지 의뢰자들이 요 
구하는것은 아닐수 있다는 약점을 가지고 있다. 신속원형 작성모형 역시 많은 성과를 
거두었다. 그럼에도 불구하고 제10장에서 서술하는바와 같이 아직도 모든 의심이 가셔 
지지 않았으며 모형은 그자체의 약점을 가지고 있다. 

한가지 해결방도는 두개의 연구방법을 결합하는것이다. 즉 이것은 그림 3-2( 폭포모 
형 )에 서 의 단계 들과 그림 3-3( 신속원형작성모형 )에 서 의 단계 들을 비 교하여 고찰할수 있 다. 
신속원형작성 은 요구사항분석 기 법 으로 리용될수 있다. 즉 달리 말하면 첫단계 는 의뢰 자 
의 실 제 요구를 결 정하는 신속원형 을 작성하는것 이 고 그 다음단계 는 폭포모형 에 대 한 입 
력 으로서 그 신속원형 을 리용하는것 이 다. 

이러한 연구방법은 쓸모 있는 측면효과를 가지고 있다. 일부 개발기업체들은 그 어 
떤 새 로운 기 법의 리용이 내재 하고 있는 위 험 으로 인하여 신속원형작성 방법 을 리용하는 
것 을 두려워 하고 있다. 폭포모형의 앞단으로서 신속원형작성 을 기 업 체들에 도입하는것 
은 관리자측에 련관된 위험요소들을 최소화하면서 그 방법에 접근할 기회를 제공해 준다. 

신속원형작성모형 은 W 장에 서 더 자세 히 분석 된 다. m 장에 서 는 요구사항확정단계 가 
서 술된 다. 다른 부류의 생 명 주기모형 을 이 제 설 명한다. 

3. 4. 증식모형 

쏘프트웨어는 작성되는것 이 아니 라 구성된다. 즉 쏘프트웨 어는 건물이 구성되는것과 
같은 방식으로 한계단씩 구성된다. 쏘프트웨어제품이 개발과정에 있는 동안에 매 계단들 
은 그전에 진행한 단계에 추가된다. 하루는 설계를 확장하고 다음날에는 또 다른 모둘을 
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코드작성한다. 완성된 제품의 구성은 완성될 때까지 이런 방식으로 점차적으로 진행된다. 

물론 이러한 전진이 매일 진행되는것은 아니다. 어떤 계약자들이 때로 잘못 세워 진 
벽들을 뜯어 버리거나 장식가들이 부주의로 깨뜨린 창유리를 교체해야 하는것과 마찬가 
지로 때때로 제품을 다시 명세작성하고 다시 설계하며 다시 코드를 작성해야 하는것，최 
악의 경우에는 이미 완성된것을 버리고 다시 시작하여야 한다. 그러나 제품이 때로는 조 
화롭게 전진한다는 사실은 쏘프트웨어제품이 한 부분씩 구성된다고 하는 기본적인 현실 
을 부정하지는 않는다. 

쏘프트웨어가 증식적으로 개발된다는 현실은 쏘프트웨어개발의 이러한 측면을 리용 
하는 모형 즉 그림 3-4 에 서 보여 준 이 른바 증식 모형 (/« creme « to / woc / e /) 의 개 발을 초래 하 
였 다. 



그림 3-4. 중식모형 


제품은 일련의 점증적인 구조물必써7쐬로서 설계，실현，통합되여 시험되는데 여기서 
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구조물은 특정한 기능을 수행할수 있도록 호상작용하는 여러가지 모둘들로부터 작성한 
코드부분들로 이루어 진다. 실례로 만일 제품이 핵잠수함을 조종하는것이라면 그때 항해 
체계는 무기조종체계로 될수 있는 구조물로 구성한다. 조작체계에서는 일정작성기가 하 
나의 구조물로 될수 있으며 따라서 파일관리체계로 될수 있게 된다. 증식모형의 매 단계 
에서 새로운 구조물은 코드작성되고 그다음 자체로 시험되는 구조물로 통합된다. 이러한 
과정은 제품이 목적하는 기능을 달성했을 때 즉 제품이 해당한 명세서를 만족시킬 때 중 
지된다. 개 발자들은 적 당하다고 생각할 때 목표제품을 구조물들로 자유롭게 분할한다. 이 
때 유일한 제약조건은 매 구조물이 현존 쏘프트웨어로 통합될 때 결과적 인 제품이 시험 
가능하여야 한다는것이다. 만일 제품이 너무 적은 구조물들로 분할되면 증식모형은 구성 
및 수정방법 으로 퇴 화된다 (3.1). 반대 로 만일 제 품이 너 무 많은 구조물들로 구성 되 면 매 
단계 에 서 적 은 량의 추가적 인 기 능을 통합시 험하는데만도 상당한 시 간이 소비 된 다. 제 품 
을 구조물들로 최 량분해하는것 은 제 품마다 개 발자마다 다르다. 증식모형 의 우점 과 약점 
은 이제 서술하기로 한다. 


3. 4. 1 . 증식모형의 분석 

폭포모형과 신속원형작성모형의 목적은 모두 완전하고 조작성이 좋은 제품을 의뢰자 
에게 배포하는것이다. 즉 의뢰자는 모든 요구를 만족시키는 제품을 가지게 되며 그에 대 
한 리용준비를 한다. 폭포모형이나 신속원형작성모형을 정확히 리용하는것은 철저히 시 
험되고 의뢰자가 제품이 원래의 개발목적으로 리용될수 있다고 확신하게 되는 그러한 제 
품을 생성하게 한다. 더우기 제품은 적당한 문서와 함께 제공되는데 이러한 문서들은 의 
뢰자측에서 리용될수 있을뿐아니 라 필요에 따라서 세 가지 류형의 유지정비 즉 적응, 완 
전 및 정정 (1.3) 유지정비가 진행될수 있게 한다. 두 모형에는 다 계획된 배포날자가 있다. 
주의 를 돌려야 할것 은 제 날자에 또는 그 날자전에 주문작업 을 완전히 완성하여 완성 된 
제 품을 배 포하는것 이 다. 

이와 대 비적 으로 증식모형은 매 단계 에서 오직 의뢰 자의 요구를 부분적 으로만 만족 
시키는 조작성 이 좋은 제 품을 배 포하게 한다. 완성된 제 품은 구조물들로 분할되며 개 발 
자들은 제품을 구조물별로 배포한다. 전형적 인 제품은 보통 5~25개의 구조물들로 구성된 
다. 매 단계 에 서 의 뢰 자는 요구의 필 요한 몫을 수행하는 조작성 이 좋은 제 품을 가지 게 
된 다. 즉 첫 구조물의 배 포로부터 의 뢰 자는 유용한 작업 을 할수 있 게 된 다. 증식모형 을 
리용하면 전체 제 품의 구성 부분들은 몇 주내 에 쓸수 있게 되 며 반면 에 폭포모형 이 나 신 
속원형작성모형을 리용하여 개발한 제품을 받기 위하여 의뢰자들은 일반적으로 여러 달 
또는 여 러 해동안 기 다리게 된다. 

증식모형 의 또 하나의 우점 은 의 뢰 자측들에 완전히 새 로운 제 품을 강요하는 외 부적 
인 영 향을 줄이는것 이 다. 증식모형 을 통한 제 품의 점 차적 인 도입 은 의 뢰 자들에 게 새 로 
운 제품을 조절할 시간을 제공한다. 변경은 매개의 확대되는 기업체들에 필수적인 부분 
으로 된 다. 왜 냐하면 쏘 프트웨 어 제품은 현실의 모형 이 기 때 문에 변경 에 대 한 요구는 배 
포된 쏘 프트웨 어 에 대 하여 필수적 인 부분으로 된 다. 변경 과 적 응은 증식모형 에 있 어 서 
본질적인것인데 반면에 변경은 제품이 개발되여 하나의 큰 단계에 도입될 때 우환거리 
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로 될수 있다. 

의뢰자들의 재정적견지에서 보면 단계적인 배포는 큰 자금지출을 요구하지 않는다. 
대 신 만일 최 초의 구조물이 두자에 대 한 높은 리 윤을 준다는데 기 초하여 신택 된 다고 하 
면 그이상의 현금류출이 있게 된다. 증식모형의 우점은 투자에 대한 리윤을 얻기 위하여 
제품을 완성 할 필요가 없 다는것 이 다. 대신에 의뢰 자는 임의의 시 각에 제 품개 발을 중지 할 
수 있다. 

증식모형의 한가지 난점은 어쨌든 매개의 추가적인 구조물이 그날까지 개발된것을 
파괴 하지 않고 현존구조에 병합되여 야 한다는것 이 다. 더우기 현존구조는 이 런 방법으로 
확장하는데 적합하여야 하며 매개의 련속적인 구조물들에 대한 추가는 간단하고 단순해야 
한다. 비록 이와 같은 열 린 구성 방식 에 대 한 요구는 확실 히 단기 적인 난점이여 도 장기 적 
으로 보면 하나의 실제적인 우점으로 될수 있다. 매 제품은 유지정비와 함께 개발된다. 개 
발기간에 명백한 명세서와 론리정연하고 응집도가 강한 설계를 작성하는것이 실로 중요하 
다. 그러나 일단 제품이 유지정비단계에 들어 가면 제품에 대한 요구들은 변화되며 본래 
의 확장은 이후의 유지정비가 불가능하게 될 정도로 론리정연하고 응집된 설계를 쉽게 파 
피해 버 릴수 있다. 이런 경우에 제품은 사실 령상태에서부터 다시 개발되여야 한다. 설계 
가 열려 져야 한다는것은 개발단계에서 선택된 모형에 관계없이 증식모형을 리용하는 제 
품개 발에 서 필수적 인것 이 아니 라 유지 정 비 에 서 필수적 인것 이 다. 이 리 하여 비 록 증식 모형 
이 폭포모형과 신속원형작성모형보다 더 주의 깊은 설계를 요구할수 있다고 하더라도 유 
지정비단계에서 보상된다. 만일 설계가 증식모형을 지원하는데 충분히 적응성이 있다면 
설계는 제품을 붕피시키지 않고 임의의 종류의 유지정비를 할수 있게 된다. 사실상 증식 
모형은 제품을 개발하는것과 그것을 확장(유지정비)하는것을 구별하지 않는다. 즉 매 확장 
은 단지 추가적인 구조물로 될뿐이다. 개발이 진행되고 있는 동안은 요구사항이 자주 변 
경된다. 즉 이 문제 에 대 해서 는 16.4.4 에서 더 자세 히 론의한다. 증식모형의 적 응성 은 이와 
관련 하여 폭포모형 과 신속원형작성모형 을 초월한 뚜렷 한 우점 을 가져 다 준다. 부정 적 인 
측면으로서 증식모형은 아주 쉽게 구성 및 수정모형으로 퇴화되여 버릴수 있다. 공정전반 
에 대한 조종이 류실되며 열린 체계로 되지 못한 결과적 인 제품은 유지정 비자들에게는 
암담한것으로 된다. 어떤 점에서는 증식모형이 용어상 모순적이다. 즉 앞으로의 확장을 포 
함하여 전체 적 인 제 품을 지 원할 어떤 설계 를 시 작하기 위하여 그 제품을 전체 적 으로 볼것 
을 개 발자에 게 요구하는것 과 동시 에 제 품을 서 로 독립인 구조물들의 렬 로서 볼것 을 요구 
한다. 만일 이런 명백한 모순을 조종하는데 충분히 숙련되지 않으면 증식모형은 불만족한 
제 줌을 초래 할수 있 다. 

그림 3-4 에 있는 증식모형 에서는 요구사항확정 과 명세작성, 구성 방식설계모두가 
여러가지 구조물의 실현을 시작하기전에 완성되여야 한다. 보다 위험한 증식모형판본 
을 그림 3-5 에 보여 주었다. 일단 의뢰자의 요구가 로출되면 첫 구조물에 대한 명세가 
작성된다. 이것이 완성되면 명세작성림은 설계림이 그 첫번째 구조물을 설계하는 동안 
두번째 구조물에 대 한 명세작성 에 로 넘 어 간다. 

이 리하여 매 림 이 이전의 구조들에서 엄는 정 보들을 리용하면서 여 러 가지 구조물들 
을 병렬로 개발한다. 이러한 방법은 결과적인 구조물들이 서로 어울리지 않을것이라는 
실제적인 위험을 초래한다. 그림 3-4 의 증식모형에서는 명세 및 구성방식설계가 첫 구조 
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물이 시작되기전에 완성되여야 한다는 요구는 처음부터 전반적인 설계를 진행하여야 한 
다는것 을 의 미한다. 그림 3-5 의 병 행 증식모형 에 서 개 발공정 이 주의 깊게 검 사되 지 않으면 
전체적인 프로젝트의 위험요소들이 붕괴된다. 그럼에도 불구하고 이러한 병행모형은 일 
부경 우에 성 공하였 다. 실례 로 큰 규모의 통신체 계 를 개 발하기 위하여 후지쯔회사에 서 그 
것을 리용하였다 [ Aoyama , 1993]. 

3. 5. 최종적프로그람작성 

최 종적 인 프로그람작성 은 [ Beck , 1999] 증식 모형 에 기 초하고 있는 쏘프트웨 어 생 산에 
대 한 론의할만한 새 로운 방법 이 다. 첫 번째 단계 는 의 뢰 자들이 제 품에 지 원하기 를 바라는 
여 러 가지 특성 들을 쏘프트웨 어생산림 이 결정하는것 이 다. 이 런 매 특성 에 대 하여 림 에서는 
의뢰자에게 그런 특성을 실현하는데 시간은 얼마나 걸리고 비용은 얼마인가를 알려 준다. 
이 첫 번째 단계 는 증식모형 에 서 요구사항확정 과 명세 작성 단계 에 해 당된다(그림 3-4). 

의 뢰 자는 비 용 대 리 득분석 (5.2) 을 리용하여 즉 자기 의 업 무특성 에 대 한 잠재 적 인 리 
득은 물론 개발림 이 제공하는 시 간과 비용에 대 한 타산에 토대하여 매 개의 련이은 구조 
물에 포함되 여 야 할 특성 들을 선택한다. 제 안된 구조물은 보다 더 작은 부분 즉 과제 
( to ? 句들로 쪼개여 진다. 

프로그람작성자는 우선 과제에 대한 시험실례를 작성한다. 그다음 한 화면상에서 어떤 동 
업 자들과 함께 작업 하여 (2 인 프로그람작성 ; pair programming ) [ Williams , Kessler , Cuningham , 
and Jeffries , 2000] 모든 시 험 실례 가 정 확히 동작한다는것 을 담보하면서 과제 를 실현해 나 
간다. 과제 는 그 다음제 품의 현재판본안에 통합된 다. 리 상적 으로 과제 를 실 현 하고 통합하 
는데는 몇시 간이상 걸 리지 않는다. 보통 여 러 2인조들이 과제들을 병 렬로 실현하며 통합 
은 련속적으로 진행된다. 과제에 대하여 리용되는 시험실례들은 이후의 모든 통합시험 
에 서 유지 되 고 리 용된 다. 최 종적프로그람작성 ( XP ) 의 여 러 특성 들은 약간 독특하다. 즉 

1. XP 개발림의 콤퓨터 들은 작은 방들로 칸을 막은 큰 방에 설 치된다. 

2. 의 뢰 자의 대 표자는 전 기 간 XP 개발림 과 함께 일 을 한다. 

3. 개별적인 사람들은 두주동안 련속적으로 일할수 없다. 

4. 전문화는 없으며 대 신 XP 개발림의 모든 성 원들은 명세작성과 설계，코드작성 
그리고 시험에 종사한다. 

5. 그림 3-5 에 보여 준 보다 위험한 증식모형에서와 같이 여러가지 구조물들이 개 
발되 기전에 전면적 인 설계 단계는 존재하지 않는다. 대 신 설계 는 제품이 개 발되는 
동안 수정된다. 이러한 처리절차를 재인자분해 ( re / actor / ng ) 라고 한다. 시험 실례가 
동작하지 않을 때 마다 실례 가 단순하고 명 백하며 모든 시 험실례 들이 만족하게 
동작한다고 개발림 이 인정할 때 까지 코드는 재조직 된 다. 

재는 많은 소규모 또는 중 규모 프로젝트들에서 성공적으로 리용된다. 이러한 프로젝 
트들에는 9명 이 한달동안 배수송에서의 관세계산체계를 개 발하는것으로부터 100명 이 1년 
동 안 가격 분석 체 계 를 개 발하는것 들 이 포함된 다 [ Beck , 1999]. 재의 우점 은 의 뢰 자들의 요 
구가 명 확치 않거 나 변화될 때 리용될수 있 다는것 이 다. 그러 나 재는 아직 은 여 러 한 판본 
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의 증식모형이 그것의 초기계약을 완성할것인가를 결정할수 있을 정도로 광범히 리용되 
지 못하고 있다. 


3. 6. 동기 및 안정화모형 

마이크로쏘프트회 사는 상업적 인 규격 쏘프트웨 어를 제 작하는 세계최대의 회사이 다. 
그 패키지의 대부분은 동기 및 안정화모형 노次 Z £) 이라고 하는 증식 모형 

의 한가지 판본을 리용하여 개 발된 다 [Cusumano and Selby , 1997]. 

요구사항분석단계 는 이 패 키지의 많은 잠정적사용자들과 면담을 하고 사용자들이 설 
정 하는 우선권을 가진 특성 목록을 추출하는것 에 의해서 관리 된다. 명세 서 가 작성된다. 다 
음으로 작업 은 셋 또는 네개의 구조물들로 분할된다. 첫번째 구조물은 가장 중요한 특성 
들로 이루어 지며 두번째 구조물은 그다음 중요한 특성들로 이루어 지는 방식으로 계속 
진행된다. 매 구조물들은 병렬로 작업하는 여러개의 작은 개발림들에 의하여 실현된다. 
하루사업 의 마감에 모든 림 들은 동기화된 다. 즉 그들은 부분적 으로 완성 된 구성 요소들을 
한데 모아 놓고 결 과적 인 제 품을 시 험 하고 수정한다. 안정 화여 toM 細 few ) 는 매 구조물들 
의 마감에 진행된다. 발견된 나머지 모든 오유들은 수정되고 구조물은 고정된다. 즉 명세 
서는 더이상 변경되지 않는다. 반복되는 동기화단계는 여러개의 구성요소들이 함께 동작 
한다는것을 담보한다. 부분적으로 구축된 제품에 대하여 이 러한 규칙적 인 실행을 진행하 
는 또 하나의 우월성은 개발자들이 제품의 조작에 대하여 신속하게 간파할수 있고 필요 
한다면 구축이 진행되는 과정 에 요구사항을 수정할수 있다는것 이 다. 만일 초기의 명세서 
가 불완전 하다면 이 모형 도 리용될 수 있 다. 동기 및 안정 화모형 은 4.5 에 서 더 고찰되 는 
데 여 기서는 림의 세부에 대 하여 론의한다. 

라선모형은 그것이 모든 다른 모형들의 여러 측면을 병합한것이기때문에 마지막에 
취급한다. 


3. 7. 라선모형 

쏘프트웨어개발과정에는 거의 언제나 항상 위험한 요소들이 포함된다. 실례로 책임 
직원은 제품이 적당하게 문서화되기전에 다시 수표를 할수 있다. 제품이 결정적으로 의 
존하고 있는 하트웨어제작자는 파산에 직면할수 있다. 시험과 품질보증에 너무 많은 자 
금이 또는 너무 적은 자금이 투자될수 있다. 주요 쏘프트웨 어제품을 개 발하는데 수십만 
딸라를 소비한 다음 기술적인 돌파구들이 전체적 인 제품을 쓸모 없게 만들수 있다. 어 
떤 개발기업체는 자료기지관리체계을 연구개발할수도 있다. 그러나 제품이 시장에 나가 
기전에 경쟁자들이 보다 낮은 가격을 가진 기능적으로 등가인 패키지를 발표하게 된다. 
그림 3-5 의 증식모형 을 리용하여 구축된 제 품의 구성 부분들은 서 로 어 울리 지 않을수 있 
다. 쏘프트웨어개발자들은 명백한 리유로 하여 이러한 위험성을 가능한껏 최소화하려고 
한다. 
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이러한 확실한 위험성들을 최소화하는 한가지 방도는 원형을 작성하는것이다. 3.3 에서 
서술한바와 같이 배포된 제품이 의뢰 자들의 실제적 인 요구를 만족시키지 않는다는 위험요 
소들을 감소시키는 좋은 방도는 요구사항확정단계에서 신속원형을 작성하는것이다. 그 다 
음단계들에서 다른 종류의 원형들이 만들어 진다. 실례로 전화회사는 장거리망을 통하여 
호출을 진행할수 있는 새 로운 효률 높은 알고리 듬을 창안할수 있다. 만일 제 품이 실현되 였 
으나 기대했던대로 동작을 하지 못하면 전화회사는 제품을 개발하는데 든 비용을 랑비하 
는것으로 된다. 이 밖에 성 이 나거 나 또는 못마땅해 하는 사용자들은 자기의 업무를 다른 
곳에 맡길수도 있다. 이러한 대본은 호출의 경로결정만을 조종하는 하나의 원형을 작성하 
고 그것을 어떤 모의기 에서 시험하는 방식으로 피할수 있다. 이 런 방식 으로 실제체계는 혼 
란되 지 않으며 경 로결정알고리 듬을 실현하는 비 용에 관하여 전화회 사는 이 새 로운 알고리 
듬을 병 합하고 있는 어 떤 전체 적 인 망조종기 를 개 발할 가치 가 있는가를 결정할수 있 다. 



j* 기 


그림 3-6. 간단한 라선모형 


93 














원형들과 기타 수단들을 리용하여 위험성요소들을 최소화하는 착상은 라선(■쨔 ra /) 모형 
의 기초를 이루고 있는 개념이다 [ Boehm , 1988]. 이러한 생명주기모형을 고찰하는 한가지 간 
단한 방법은 그림 3-6 에서 보여 준바와 같이 매 단계 에서 하나의 폭포모형 을 위 험성분석 
에 선행시키는 방법 이 다(그림의 일부분은 라선모형을 반영하도록 이 그림 에 해 당한 부분이 
그림 3—7로 다시 그려 졌다.). 



매 단계 를 시 작하기전에 위 험성 을 조종 (또는 해소)하기 위한 시 도가 진행된다. 이 단 
계에서 중요한 모든 위험성을 해소하는것이 불가능하면 프로젝트는 즉시에 끝난다. 

원형은 어떤 부류의 위험에 대한 정보들을 제공하는데 효과적으로 리용될수 있다. 
실례로 시간적인 제약은 보통 원형을 작성하고 그 원형이 필요한 성능을 실현할수 있는 
가를 측정 함으로써 시 험할수 있 다. 만일 원형 이 제 품의 관련된 특징 들에 대 한 하나의 정 
확한 기능적인 표현으로 된다면 원형에 대하여 진행되는 측정은 개발자들에게 시간적인 
제 약의 달성 여부에 관한 하나의 훌륭한 착상을 주게 된다. 

다른 령역 에서의 위 험요소들은 원형작성 을 보다 어 렵게 한다. 실례 로 제 품을 개 발 
하는데 필요한 쏘프트웨어직원들이 고용될수 없다거나 또는 책임직원이 제품이 완성 
되 기전에 다시 수표하는 그러한 위 험 요소들이 자주 발생한다. 또 하나의 잠재 적 인 위 
험 은 어 떤 특정한 개발림 이 하나의 특정한 대 규모제 품을 개 발할수 있 을 정 도의 자격 
이 없 다는것 이 다. 어 떤 가정 에 서 리용하는 제 품들을 개 발하는데서 성 공한 계 약자들은 
큰 사무소에 서 리용하는 복잡한 제 품들을 개 발할수 없 을수도 있다. 마찬가지 로 소규모 
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쏘프트웨 어와 대규모쏘프트웨 어사이 에는 본질적 인 차이 가 있으며 원형 작성은 거의 리 
용되지 않는다. 이러한 위험요소들은 어떤 훨씬 작은 파라다임에 대하여 림의 성능을 
시 험 함으로써 해 결될수 없으며 이 파라다임 에서 대 규모쏘프트웨 어 에 특정 한 림 조직 에 
대한 문제점들은 발생할수 없다. 원형작성이 진행될수 없는 또 한가지 위험은 하드웨 
어공급자들의 배포계약을 타산하는것이다. 개발자들이 채용할수 있는 하나의 전략은 
공급자들의 이전의 뢰 자들이 얼마나 잘 취급되 는가를 결정 하는것 이지만 과거의 성능이 
결코 앞으로의 성능을 명백하게 예언하여 주는것은 아니 다. 배포계 약서에서 벌금에 대 
한 조항은 필수적인 하드웨어가 제정된 시간에 배포될것이라고 담보하는 한가지 방도 
로 되지만 만일 공급자들이 그러한 조항을 포함시키는데 동의하지 않는다면 어떻게 
되겠는가? 지어 벌금조항에 따라서 지연된 배포가 발생할수도 있으며 결국에는 여러 
해동안 법적소송을 당할수 있는 재판에 기소될수도 있다. 그럭저 럭 하는 사이 에 계 약된 
하드웨 어 의 미 배 포가 계 약된 쏘프트웨 어 의 미 배 포를 발생 시 키 는것 으로 하여 쏘프트웨 
어개발자들은 파산에 직면하게 된다. 간단히 말하면 원형작성이 일부 같은 령역의 위 
험요소들을 감소시키는 반면에 다른 령역의 위험요소들은 기껏해서 부분적으로 해소 
할수 있으며 또 다른 령역의 위험요소들은 전혀 해소할수 없을수도 있다. 라선모형의 
총체적인 륜곽을 그림 3-8 에 보여 준다. 



그림 3-8. 완전한 라선모형 [Boehm,1988]. (©1988, IEEE.) 
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반경은 날자별 루적비용을 나타내며 각도는 라선모양의 전진과정을 나타낸다. 매 라 
선의 주기는 단계 에 대응한다. 매 단계는 그 단계의 목적과 그 목적을 달성하기 위한 방 
도 그리 고 방도들에 대 한 제 약들을 결정하는것 으로써 시 작된다(상단 왼쪽 4.4 분구). 이 
공정은 이 목적 들을 달성 하기 위한 하나의 전략을 초래한다. 다음으로 그 전략은 위 험성 
의 견지에서 분석된다. 일부 경우에 하나의 원형을 구성함으로써 모든 잠재적인 위험요소 
들을 해석 하기 위한 시도들이 진행된다. 만일 위험요소가 명백 히 해소될수 없다고 하면 프 
로젝트는 그 즉시에 끝나고 만다. 그러나 일부 정황하에서 이 프로젝트를 어떤 훨씬 작은 
규모로 계 속하여 진행 하기 위한 결심 이 이 루어 질수 있다. 만일 모든 위험요소들이 성공 
적 으로 해 소되 면 그 다음개 발단계 가 시 작된 다(하단 오른쪽 2.4 분구). 라선모형 의 이 4개분 
구는 순수한 폭포모형에 대응한다. 마지막으로 그 단계의 결과들이 평가되고 다음단계가 
계획된 다. 

라선모형 은 넓 은 분야의 제 품들을 개 발하는데 성 과적 으로 리용되 였 다. 라선모형 이 
생 산성 을 높이 기 위한 다른 방법 들과 결 합되 여 리 용된 25개 의 프로젝 트에 서 매 프로젝 트 
의 생산성은 이전보다 적어도 50%까지 늘어 났으며 대부분의 프로젝트들에서는 100%까 
지 늘어 났다 [ Boehm , 1988]. 라선모형 이 주어 진 프로젝 트에 대 하여 리 용되 여 야 하는가를 
결 정 하기 위하여 그것 의 우점 과 약점 에 대 하여 평 가한다. 

3. 7. 1 . 라선모형의 분석 

라선모형은 여러가지 우점을 가지고 있다. 다른 대안들과 제약에 대한 강조는 현존 
쏘프트웨어 의 재 리용 (8.1) 과 특정한 목적 으로서 의 쏘프트웨 어품질의 병 합을 지 원한다. 이 
밖에 쏘프트웨 어개 발에 서 의 일 반적 인 문제 들은 어 떤 특정한 단계 에서의 제 품이 적 당하게 
시험될 때 에 결정된다. 시험 에 많은 시 간을 소비하는것은 곧 돈을 랑비 하는것 이며 제 품 
의 배포가 지나치게 지연되게 할수도 있다. 반대로 시험이 진행되면 배포된 쏘프트웨어 
는 잔류오유를 포함하고 있으므로 개발자들에게 기분 나른 결과를 가져다 준다. 라선모 
형 에서는 충분한 시험 을 진행하지 않거 나 또는 지 나치게 시 험을 진행 함으로써 위험요소 
들이 발생한다. 아마도 라선모형 의 구조내 에 서 가장 중요한 유지 정 비 는 단순히 또 하나 
의 라선형주기 로 된다. 즉 본질 에 있어 서 유지 정 비 와 개 발사이에 는 구별 이 없 다. 이 리 하 
여 무식한 쏘프트웨어 전문가들에 의하여 때때 로 유지 정 비 가 손해 를 보는것과 같은 문제 
는 제기되지 않는다. 왜냐하면 유지정비는 개발과 같은 방법으로 취급되기때문이다. 

라선모형의 응용에 대 한 제 약이 존재한다. 특히 그 표현형 식 에서 모형 은 대 규모쏘프 
트웨어의 내부적개 발에 있어서 배제 되 는 경 향이 있다 [ Boehm , 1988]. 내부적 인 프로젝 트 
즉 개발자와 의뢰자가 모두 같은 기관의 성원으로 되는 경우를 고찰하자. 만일 위험분석 
결과 이 프로젝 트가 종결되 여 야 한다는 결론에 도달하게 되 면 기 관내 쏘프트웨 어개 발자 
들은 어떤 다른 프로젝트를 수행하도록 배 치될수도 있다. 그러 나 일 단 개 발기 업 체와 외 
부의뢰자사이에 계약이 체결되면 어느 한 측이 이 계약을 끝내려고 하는 시도는 계약위 
반에 대 한 법 적 소송을 초래할수 있 다. 그렇 기 때 문에 계 약쏘프트웨어 인 경 우에 모든 위 험 
분석 은 계 약이 체 결되 기 전에 의 뢰 자와 개 발자들에 의하여 수행 되 여 야 하며 라선모형 에 서 
처럼 진행되지 말아야 한다. 
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라선모형에 대한 두번째 제 약은 프로젝트의 크기와 관련되여 있다. 특히 라선모형은 
대규모쏘프트웨 어 에만 적용될수 있다. 만일 위험분석 을 진행 하는 비용이 프로젝 트전체의 
비용과 맞먹거 나 또는 위험분석을 진행 하는것 이 잠재적 인 리득에 크게 영향을 주게 된다 
면 위험분석을 진행하는것은 아무런 의미도 없다. 그대신 개발자들은 위험요소들에 얼마 
나 많은 비용이 소비되는가를 결정하고 그다음 위험분석을 진행하는데 얼마만한 비용이 
소비되는가를 결정하여야 한다. 

라선모형의 한가지 중요한 우점은 그것이 위험요소에 의하여 구동된다는것인데 이것 
聲 또한 하나의 약점으로 될수도 있다. 만일 쏘프트웨 어 개 발자들이 가능한 위 험요소들을 
지적하고 그 위험요소들을 정확하게 분석하는데 숙련되여 있지 않다면 프로젝트가 사실 
상 불행에 빠지게 될 때에 개발림이 모든것은 잘 진행되고 있다고 믿게 되는 실제적인 
위험성 이 존재 한다. 만일 개 발림성원들이 충분한 자격 이 있는 위험요소분석 가들이 라면 
관리 자측은 라선모형을 리용하기로 결정 하게 된다. 

3. 8. 객체지향생명주기모령 

객체지향파라다임을 리용한 경험은 공정의 단계들 또는 단계의 부분들사이에서 진행 
되는 반복이 구조화파라다임을 리용할 때보다 객체지향파라다임을 리용할 때 보다 더 일 
반적인 현상으로 된다는것을 보여 주었다. 객체지향생명주기모형은 명백하게 반복에 대한 
요구를 반영하도록 제 한되 였 다. 이 와 같은 하나의 모형 은 그림 3-9 에 서 보여 준 분수모형 
이 다 [ Henderson-Sellers and Edwards , 1990]. 

여러가지 단계를 나타내는 원들은 활동들사이의 겹침을 명백히 반영하면서 겹쳐있 
다. 단계안의 화살표들은 그 단계안에 서 의 반복을 나타낸 다. 유지 정 비 에 관한 원은 객 체 
지 향파라다임 이 리 용될 때 유지 정 비 에 대 한 노력 이 감소되 는것 을 나타내 기 위하여 더 작 
게 그려 주었다. 

분수모형 외 에 재 귀/병 렬생 명 주기 [ Berard , 1993] 와 원형 려 행 형 태 설계 [ Booch , 1994] 그리 
고 통합쏘프트웨 어 개 발공정 에 토대 한 모형 [ Jacobson , Booch , and Rumbaugh , 1999] 을 비 롯하 
여 여 러 가지 객체지향생 명 주기모형 들이 제 안되 였 다. 이 모든 모형 들은 반복적이 며 병 렬 
적인 일련의 형태들을 병합하고 있으며 증식개발 (3.4) 을 지지하고 있다. 이러한 생명주기 
모형의 위험은 다음과 같다. 그것들이 필요이상의 효과를 얻기 위한 시도로서 오해될수 
있으며 또 그로 말미암아 개발림성원들이 처음에는 제품의 어느 한 부분을 설계 하고 다 
음에는 또 다른 부분을 분석하며 그다음 전혀 분석 되 지도 설계 되 지도 않은 세번째 부분 
을 실현하는 방식 으로 매 개 단계들사이를 우연적 으로 이동하는 완전히 비학문학적 인 쏘 
프트웨 어 개 발형 식 에 로 이 끌어 갈수 있 다는것 이 다. 다음의 《 알고 싶은 문제》에 서 는 이 
와 갈은 희망하지 않는 방법 에 대 하여 보다 상세히 보여 주고 있다. 더 좋은 방법은 객 
체지향파라다임의 실체는 바로 주기적인 반복과 세련이 명백히 요구된다는것을 옳게 인 
식하는것외 에 선형공정 (3.3 에 서 의 신속원형작성모형 이 나 또는 그림 3-9 에 서 의 중심수직 
선과 갈은)을 하나의 전체 적 인 목적 으로 취 하는것 이 다. 이 문제 는 단순히 객체 지향파라 
다임과 련관된 한가지 새로운것이라는것이 제기될수도 있다. 
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는 쏘프트웨 어생산의 고유한 속성 이며 특히 객체지향파라다임 에서 그러 하다. 


3. 9. 생명주기모형의 비교 

6개의 서 로 다른 클라스에 대 한 쏘프트웨 어생명주기모형들을 그것들의 우단점 에 특 
별 한 주목을 돌리 면서 시 험하였 다. 구성 및 수정모형 (3.1) 은 피 하여 야 한다. 폭포모형 (3.2) 
은 이미 알려 진 개념이다. 그것의 우점은 리해되며 그래서 그것의 약점도 리해된다. 신 
속원형작성모형 (3.3) 은 배 포제 품이 실지 의 뢰 자가 요구한것 이 아닐수 있 다고 하는 폭포모 
형 에서의 특정한 약점 에 대 처하여 개 발되 였다. 폭포모형 은 잘 알려 져 있지 만 새롭게 나 
온 신속원형작성모형 에 대 해서는 잘 알려 져 있지 않다. 신속원형작성모형 은 제10장에서 
보여 준바와 같이 일정한 자체의 문제점을 가질수 있다. 하나의 다른 방도는 3.3.1 에서 
제 기한바와 같이 두 모형의 우점을 결합하는것 이 다. 이 모형 은 성 공적 임에도 불구하고 
일 부 결 함을 가지 고 있 다. 최 종적 인 프로그람작성 (3.5) 은 론의할만한 방법 이 다. 동기 및 
안정화모형 (3 .句은 마이크로쏘프트회사에서 큰 성과를 보았다. 그러나 다른 


생명주기모형 

우 점 

약 점 

구성 및 수정모형 (3.1) 

유지정비를 요구하지 않는 작 
은 프로그람에서는 좋다. 

중요한 프로그람에 대 하여서는 전혀 
충분하지 않다. 

폭포모형 (3.2) 

문서 구동숙련 방법 

배포된 제품은 의뢰자의 요구를 만 
족시키 지 않는다. 

신속원형 작성 모형 (3.3) 

배포된 제품은 의뢰자의 요구 
를 만족시킨다. 

모든 의심이 증명되지 않았다. 

중식모형 (3.4) 

초기투자가 최대로 된다. 유지 
정비가능성을 촉진시킨다. 

열린 구성 방식 을 요구한다 . 구성 및 
수정모형 으로 퇴 화될수 있다. 

최 종프로그람작성 (3.5) 

초기 투자가 최대로 된다. 의뢰 
자의 요구가 모호할 때 잘 작 
업 한다. 

아직 널리 리용되지 않는다. 

동기 및 안정화모형 
(3.6) 

미래의 사용자의 요구를 만족 
시킨다. 

구성요소들을 성과적 으로 통합 
할수 있다. 

다른 기 업체들에서는 마이 크로쏘프트 
회사보다 널리 리용하지 않고 있다. 

라선모형 (3.7) 

우의 모든 모형의 특징을 병 
합한다. 

큰 규모의 내 부리용제품들에만 리용 
가능하다. 

개발자들은 위험성분석 및 위험해소 
능력이 있어야 한다. 

객체지향모형 (3.8) 

단계 안에서，단계들사이에 반복 
가능하다. 

CABTAB 로 퇴화될수 있다. 


그림 3-10. 3장에서 설명한 생명주기모형의 비교와 취급한 절 
기 업 분야에 서 는 뚜렷 한 성 과가 증명 되 지 않았다. 또 다른 방도는 라선모형 (3.7) 을 리용하 
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는것인데 그것은 개발자들이 위험분석과 위험해소에 충분히 숙련되였을 때에만 가능하다. 
고려해야 할 요인은 객체지향파라다임이 리용될 때 생명주기모형이 반복적이여야 하며 
즉 그것 이 반결 합을 지 원해 야 한다는것 이 다 (3.8). 이 장에 서 취 급한 여 러 가지 생 명 주기모 
형의 우단점은 그림 3-10 에 개괄되여 있다. 

매 쏘프트웨어개발기업체는 그 조직과 경영， 종업원들과 쏘프트웨어공정에 알맞는 
생명주기모형 을 결정하여 야 하며 현재 개 발중에 있는 특정한 제품의 성 질에 따라 모형 을 
바꾸어야 한다. 이러한 모형은 그것의 우점은 리용하고 약점은 최소화하는 방식으로 여 
러가지 생명주기모형의 적절한 측면들을 병 합할것 이 다. 

O 야 

-U- 一 I 

구성 및 수정모형 (3.1), 폭포모형 (3.2)，신속원형작성모형 (3.3), 증식모형 (3.4)，최 종 
적프로그람작성(3.5)，동기 및 안정화모형(3.6)，라선모형(3.7)，객체지향생명주기모형 
(3.8) 을 비롯한 여러가지 생명주기모형들이 서술되였다. 3.9 에서는 이러한 생명주기모 
형 들을 비 교대 조하고 특정한 프로젝 트에 대 한 생 명 주기모형 의 선택 에 관한 제 안들이 
제시 되였 다. 


보 충 

폭포모형 은 처 음으로 문헌 [ Royce , 1970] 에서 제시 되 였다. 폭포모형 에 대 한 분석 을 
문헌 [ Royce , 1998] 의 1장에서 주었다. 

신속원형작성 에 대 한 소개 는 문헌 [Connell and Shafer , 1989] 와 [ Gane , 1989] 에 제 시 
되 였 다. 콤퓨터 지 원원형작성 의 역 할은 문헌 [Luqi and Royce , 1992] 에 서 찾아 볼수 있 다. 
1995년 2월에 발표된 IEEE Computer ^] 신속원형 작성 에 대 한 몇 개의 기사를 주었다. 증식 
모형의 한가지 류형인 진화적배포모형 에 대 한 설명은 문헌 [ Gilb ，1988] 에서 찾아 볼수 
있 다. 병 행 증식 모형 은 문헌 [ Aoyama ，1993] 에 서 술되 여 있 다. 동기 및 안정 화모형 은 문헌 
[Cusumano and Selby , 199刀에 서는 개 괄하여 주었으며 문헌 [Cusumano and Selby , 1995] 에 
서 상세히 서술하였다. 동기 및 안정화모형은 문헌 [ McConnell , 1996] 에서 파악할수 있다. 
라선모형은 문헌 [ Boehm , 1988] 에서 서술되였고 TRW 쏘프트웨어 생산체계에 대한 응용은 
문헌 [Boehm et al „ 1984] 에서 찾아 볼수 있다. 최종적프로그람작성은 문헌 [ Beck , 1999] 
와 문헌 [ Beck , 200이에서 서술되였고 재인자분해는 문헌 [Fowler et al „ 1999] 의 주제 이 
다. 

위 험성 분석은 문헌 [ Boehm , 1991; Jones , 1994 c ; Karolak , 1996 ; and Keil , Cule , 
Lyytinen and Schmidt , 1998] 에 서술되여 있다. IEEE Software 1997년 5월/6월호에 위험성 
관리에 관한 10개의 기사가 있다. 

객 체 지 향생 명 주기 모형 들은 문헌 [ Henderson-Sellers and Edwards , 1990; Rajlich , 1994; 
and Jacobson , Booch , and Rumbaugh , 1999] 에 서 술되 여 있 다. 많은 다른 생 명 주기 모형 들이 
제 기되 고 있다. 실례 로 인간적 인자들을 강조한 하나의 생명주기모형은 문헌 [Mantei and 
Teorey , 1988] 에 서 술되 였으며 문헌 [Rajlich and Bennett , 200이에서는 유지정 비지향생 명 
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주기모형을 서술하고 있다. 쏘프트웨어공학연구소에서 제기한 생명주기모형은 문헌 
[Landis et al „ 1992] 에 서 술되 여 있 다. IEEE Software 2000 년 7 월/ 8 월 호에 는 최 종적프로그 
람작성의 한 구성부분인 2 인프로그람작성에 대한 실험을 서술하고 있는 문헌 [ Williams , 
Kessler , Cunningham , and Jeffries , 200 이을 비롯한 쏘프트웨어생명주기모형에 대한 여러개 
의 론문들이 있 다. 국제쏘프트웨 어개 발공정토론회 회 보는 생 명 주기모형 에 관한 정 보를 
주는 유용한 문헌으로 되고 있다. [ ISO/IEC 12207, 1995] 는 쏘프트웨어생명주기공정에 대 
한 표준으로 되고 있다. 


문 제 

3.1. 당신이 3.7485 기의 거 물수를 소수점 아래 4 자리 까지 계 산하는 제 품을 개 발해 야 
한다고 가정 하자. 일 단 제품이 실현되 여 시험되면 그 제품은 버리게 된다. 당신은 어떤 
생 명 주기모형 을 리용하려 고 하는가? 대 답과 그 리유를 밝히 시 오. 

3.2. 당신은 쏘프트웨 어공학고문인데 단음식 을 생 산하여 여 러 식 당들에 판매하는 회 
사인 《사멸되 여 가는 단음식; i 저 p/oraWy Z ) eca 쇼까 Ztawerto 》 의 재정부지배 인에게 호출되 
였다. 그 녀 자는 자기 들이 생 산하여 여 러 식 당들에 배 포할수 있 도록 여 러 가지 원 료들을 
사들이고 단음식 들이 생 산되 여 식 당들에 배 달될 때 그것 들을 조사하는것 으로부터 시 작하 
는 회사의 제품을 검사하는 제품을 개발할것을 당신의 기업체에 부탁한다. 당신은 그 프 
로젝 트에 대 한 생 명 주기모형 을 선택하는데 서 어 떤 기 준을 리용하겠는가? 

3.3. 문제 3.2 의 쏘 프트웨 어 를 개 발하는데서 위 험요소들의 명세 를 작성 하시 오. 매 위 
험요소을 해소하기 위하여 어떻 게 하려고 하는가? 

3.4. 회 사《사멸되 여 가는 단음식》을 위한 창고조종제 품의 개 발이 아주 성 공적 이 다. 
결과 이 회 사는 소매 기 업 체 들은 물론 식 당들을 위하여 음식 을 준비 하고 판매하는 여 러 
회사들에 팔아 줄 COTS 패키지로서 제품이 다시 작성될것을 요구한다. 그러므로 새로운 
제품은 새 로운 하드웨 어와 조작체계 에 이식 가능하고 쉽게 적응할수 있어 야 한다. 문제 
3.2 의 대 답에 있는 프로젝 트와 차이 나는 이 프로젝 트에 대 한 생 명 주기모형 을 선택하는데 
서 어 떤 기 준을 리용하는가? 

3.5. 증식모형 에 대 하여 리 성 적 으로 응용할수 있는 제 품의 종류를 서 술하시 오. 

3.6. 증식모형 이 난관에 부닥치 게 되 는 상황의 류형 들을 서 술하시 오. 

3.7. 라선모형에 리성적으로 응용할수 있는 제품의 종류를 서술하시오. 

3.8. 라선모형 이 적합치 않은 상황의 류형을 서술하시오. 

3.9. 폭포와 분수에서 공통적 인것은 무엇 인가? 폭포모형과 분수모형 에서 공통적 인것 
은 무엇이며 그것들은 어떻게 다른가? 

3.10. (과정 안상 목표) 부록 1에 서술된 브로드랜즈지 역 아동병 원을 위 해서 는 어떤 生 
프트웨어생명주기모형 을 리용하겠는가. 대 답과 함께 그 리유를 밝히시 오. 

3.11. (쏘프트웨 어 공학독본) 교원 이 문헌 [ Beck , 1999] 의 복제 본을 배 포해 줄것 이 다. 
최 종적프로그람작성 방법 을 리용하는 회 사에 서 일 하고 싶은가? 
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제 4 장. 개 발 림 


충분한 자격 이 있는 잘 숙련된 쏘프트웨 어공학자들이 없다면 쏘프트웨 어프로젝 트는 
실패의 운명에 처하게 된다. 그러나 능력 있는 사람들을 얻기는 쉽지 않다. 즉 개발림은 
림의 성원들이 다른 성원들과 협력하여 능률적으로 작업할수 있도록 조직되여야 한다. 
림의 조직과 관련한 문제 가 이 장의 주제 이 다. 

4. 1 . 개발팀의 조직 

대부분의 제품들은 너무 커서 주어 진 제 약된 시간안에 한명의 쏘프트웨어전문가가 
완성할수 없다. 결과 제품은 림으로 조직된 전문가들의 그룹에 맡겨 져야 한다. 실례로 
명 세작성단계 를 고찰해 보자. 목표제 품을 2개 월안에 개 발하기 위 하여 서 는 명 세작성 관리 
자의 지도밑에 림으로 조직된 세명의 명세작성전문가들에게 과제를 맡겨야 한다. 이와 
류사하게 설계과제는 설계 림성원들에게 나누어 주어야 한다. 

이 제 한 사람이 1년동안 작성해 야 할 코드를 포함하고 있는 제 품이 3개 월안에 작성 
되여야 한다고 가정하자. 해답은 명료하다. 즉 만일 한명의 프로그람작성자가 1년동안에 
제품을 개발할수 있다면 4명의 프로그람작성자는 3개월동안에 해낼수 있다. 

물론 이렇게 일하지는 못한다. 실천적으로는 4명의 프로그람작성자가 개발해도 거의 
1년이 걸리고 결과적인 제품의 품질도 한명의 프로그람작성자가 혼자서 제품을 개발하는 
것보다 더 떨어 질수 있다. 그 리유는 일부 과제는 분할될수 있지만 다른 과제들은 개 
별적으로 진행되여야 한다는것이다. 실례로 만일 한명의 농장원이 W 일동안에 딸기를 수 
확할수 있 다면 갈은 량의 딸기 를 10명 이 하루동안에 수확할수 있다. 다른 한편 한명 의 
녀성이 9달동안에 아이를 만들수 있지만 9명의 녀성이 한달동안에 아이를 만들수는 없다. 

달리 말하면 딸기따기 와 같은 과제 는 완전히 분할할수 있지 만 아이 를 낳는것 과 같은 
다른 문제들은 분할할수 없다. 아이를 낳는것과는 달리 림성원들에게 코드작성을 분배함 
으로써 림성원들에게 실현해야 할 과제를 분할해 줄수 있다. 그러나 림프로그람작성은 
림성원들이 어떤의미 있고 효과적인 방식으로 서로 대화해야 한다는데서 딸기따기와는 
다르다. 실례 로 제 인과 네드가 두개의 모둘 ml 와 m 2 를 코드작성해 야 한다고 하자. 많은 
일들이 잘못 진행 될수 있다. 실례 로 제 인과 네 드는 모두 ml 을 코드작성 하고 m 2 는 무시 
할수도 있 다. 또는 제 인은 ml 을 코드작성 하고 네 드는 m 2 를 코드작성할수도 있 다. 그러 나 
ml 이 m 2 를 호출할 때 그것은 4개의 인수를 넘겨 주고 네드는 5개의 인수를 요구하는 방 
법 으로 m 2 를 코드작성 한다. 또는 ml 과 m 2 에 서 인수들의 순서 가 다를수 있 다. 또는 순서 
는 같지만 자료형이 약간 차이날수 있다. 이러한 문제들은 개발기업체를 통해 보급되지 
않은 설계 단계 에서 만들어 진 결정 에 의해서 생겨 나게 된다. 이 런 문제 는 림 프로그람작 
성자들의 기술적 인 능력과는 아무런 관련도 없다. 림의 조직은 관리상의 문제 이 다. 즉 관 
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리 자측은 매 림 이 고도로 능률적 이도록 프로그람작성 림을 조직해 야 한다. 

쏘프트웨어의 림 조직 에서 제 기될수 있는 다른 류형의 난점 은 그림 4-1 에 보여 주었다. 



그림 4-1. 세명의 를퓨터전문가들사이의 통신경로(실선)， 

네번째 전문가가 그들과 련결되여 있는 경우(점선) 

프로젝 트에 대 하여 작업하는 세명의 콤퓨터전문가들사이 에 는 세개의 통신선로가 존 
재한다. 이 제 작업 이 잘못되 여 최 종기 간이 거 의 다가오고 있으나 과제 가 아직 완성 되 지 
않았다고 하자. 명 백한것 은 림 에 네번째 전문가를 보충하는것 이 다. 그러 나 네번째 전문가 
가 림에 보충될 때 해야 할 첫번째 일은 다른 세명이 어느 날까지 무엇을 완성해야 하고 
아직 무엇 이 완성 되 지 못했는가를 자세 히 설명해 주는것 이 다. 달리 말하면 뒤 늦게 쏘프트 
웨 어프로젝 트에 성 원을 보충하는것 역 시 개 발이 더 늦어 지 게 한다는것 이 다. 이 원리 를 
프레드 브룩스가 OS /360 의 개발을 하면서 그것을 발견한후부터 브룩스의 법칙 ( Brooks ’ s 
Law ) 으로 불리워 졌다 [ Brooks , 1975]. 

큰 기업체에서 림들은 프로그람작성자들이 독립적으로 작업하는 동안 쏘프트웨어생 
산의 매 단계에서 특히 실현단계에서 리용되게 된다. 따라서 실현단계는 몇명의 콤퓨터 
전문가들에게 과제률 분할하는 최초의 단계로 된다. 보다 작은 일부 기업체들에서는 하 
나의 개 별적 인 림들에 요구사항확정 과 명세작성，설계를 맡길수 있으며 그다음 2 또는 3 
명의 프로그람작성자들로 이루어 진 림에 의해서 실현단계가 진행된다. 림들은 실현단계 
에서 가장 과중하게 리용되 기 때 문에 림 조직 문제 는 실현단계 에 서 가장 날카롭게 제 기 된다. 
따라서 이 장의 나머지부분에서 비록 문제점들과 그 문제점에 대한 해결이 다른 모든 단 
계들에서 마찬가지로 적용될수 있다고 해도 림의 조직문제는 실현단계의 범위내에서 제 
시된 다. 

프로그람작성 림조직 에 대 한 두개 의 극단적 인 방법 들이 있는데 하나는 민주적 인 림 이 
고 다른 하나는 책 임프로그람작성 자림이 다. 여 기서 취 한 방법 은 매 방법들을 서 술하고 
그 우단점을 강조하며 그다음 이 두 극단의 가장 좋은 특성들을 병 합한 하나의 프로그 
람작성 림 을 조직하는 다른 방법 들을 제 기하는것 이 다. 
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4. 2. 민주적팀방법 


민주적 림조직에 대하여서는 19기년에 와인버그가 처음으로 서술하였다 [ Weinberg , 
19기]. 민주적림의 밑바탕에 놓여 있는 기초적 인 개 념은 주관이 없는 프로그람작성 
{egoless programming ) 0 ] >4, 와인버 그는 프로그람작성 자들은 자기 들이 작성 한 코드에 매 우 
애 착을 가질수 있다고 강조하였 다. 때때 로 그들은 자기들이 작성한 모둘들에 자기 들의 
이 름을 달아 부르고 있 다. 즉 그들은 자기 들이 작성한 모둘을 자기 자신의 확장으로 생 각 
한다. 이로부터 생기는 난점은 모둘을 자기자신의 확장이나 주관으로 보는 프로그람작성 
자들은 확실히 자기들의 코드에서 모든 오유를 찾아 내려고 하지 않는다는것이다. 만일 
에 오유가 존재한다면 그것을 바그 (6 wg ) 라고 부르는데 그것은 승인없이 코드에 기여 들 
어 와서 코드가 침입 에 대 처하여 보다 더 열정적 으로 감시할 때 에만 막을수 있는 그런 
벌레와 같다. 이러한 립장은 몇년전에 쏘프트웨어가 아직 착공카드로 입력되고 있을 때 
그 벌 레쫓개 (別 oo - Swg ) 라고 부르는 공기식분무기 를 파는것 으로써 재 미 있 게 풍자되 였 다. 
벌레쫓개로 프로그람카드를 분무하는것은 그 어떤 벌레도 코드에 기생할수 없다고 담보 
한다는것 을 설 명 하고 있다. 프로그람작성 자들이 자기 자신의 코드와 매 우 밀 접하게 련 관 
되여 있는데서 생기는 문제에 대한 와인버그의 해결방안은 주관이 없는 프로그람작성이 
다. 사회적인 환경은 재구성되여야 하며 따라서 프로그람작성자들에 대한 평가도 달라 
져야 한다. 모든 프로그람작성자들은 자기들의 코드에서 오유를 찾도록 림의 다른 성원 
들을 부추겨 야 한다. 오유가 존재 한다는것을 그 어떤 나쁜것으로 간주될것 이 아니 라 일 
반적이고 허용할수 있는 사건으로서 간주하여야 한다. 즉 심사자들이 취해야 할 태도는 
코드작성 에 서 오유를 범하는 프로그람작성 자에 대 하여 비 웃을것 이 아니 라 충고를 받았다 
고 감사히 여겨 야 한다는것 이 다. 

10명 이내의 주관이 없는 프로그람작성 자들로 이루어 진 그룹은 민주적 인 림 을 구성 
한다. 와인버그는 이러한 림과 함께 일하는 경우에 관리상 곤난하다고 경고하였다. 그러 
면 관리상 성공하는 길을 생각해 보자. 프로그람작성자가 경영자의 지위에 등용되였을 
때에 그의 동료프로그람작성자들은 등용되지 않고 다음단계의 등용에서 보다 더높이 올 
라 서려고 노력해야 한다. 이와 대비적으로 민주적인 림은 지도하는 사람도 없고 다음 
수준으로 승급하려고 애 쓰는 그런 프로그람작성자도 없으며 다같이 공동의 목적을 달성 
하기 위하여 일 하는 하나의 그룹이 다. 중요한것 은 림 이 단합되 고 호상존중하는것 이 다. 

와인버 그는 민주적 인 림 에 의해서 우수한 제 품이 개 발될수 있 다고 하였 다. 관리 자측 
은 림의 명목상 관리 자(정의 에 의하면 민주적 인 림에는 지도하는 사람이 없다.)에 게 상금 
을 주기로 결정하였다. 명목상 관리자는 그것을 개인적으로 받아 들이는것을 거절하면서 
림의 모든 성원들에게 꼭같이 나누어 주어야 한다고 말했다. 관리자는 그가 더 많은 돈 
을 빼 내 려고 하고 있고 림(특히는 명목상관리 자이다.)은 오히 려 이 단적 인 생각을 가지고 
있다고 보았다. 관리자는 명목상의 관리자에게 돈을 받으라고 강요하였는데 그때 그는 
림의 성원들에게 꼭같이 나누어 주었다. 그다음에 전체적 인 림은 다시 다른 회사와 하나 
의 림 으로서 서 명 하고 결 합한다. 

민주적인 림의 우점과 결함을 보기로 하자. 
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4. 2. 1 • 민주적팀에 대한 분석 

민주적 림 방법의 중요한 우점은 오유찾기 에서 긍정적 인 태도를 취 한다는것 이 다. 오유 
를 더 많이 찾으면 찾을수록 민주적인 림의 성원들은 더 좋아 한다. 이러한 긍정적인 태 
도는 보다 빨리 오유를 발견하도록 하며 이로부터 코드의 질이 높아 진다. 그러 나 여기 
에는 일부 중요한 문제점들이 있다. 이미 강조한바와 같이 관리자들은 주관이 없는 프로 
그람작성을 받아 들여야 한다는 난점을 가지고 있다. 이밖에 15년의 경험을 가진 프로그 
람작성 자는 동료프로그람작성 자들 특히 는 초학도들에 의하여 코드가 평 가되 는것 을 싫어 
한다. 

와인버 그는 주관이 없는 림들이 자원적 으로 형성되 며 외부로부터 강요될수는 없다고 
생 각했다. 민주적 인 프로그람작성 림 에 대 하여 실험 조사가 거의나 진행 되 지 않았지만 와 
인버 그의 경험은 민주적 인 개발림 이 아주 능률적 이 라는것 이 다. 만테 이 ( Mantei ) 는 특히 프 
로그람작성 림 [ Mantei , 1981] 에 대 해서 가 아니 라 일반적 인 그룹기 업 체의 리 론과 그에 대 한 
경험에 기초한 론증을 리용하여 민주적인 림조직을 분석하였다. 그는 중앙집권적이 아닌 
그룹은 문제 가 어 려 울 때 가장 훌륭히 일하며 민주적 인 개발림 은 연구환경 에 서 기 능을 
잘 수행한다는것을 제기하였다. 경험은 해결하기 힘든 문제가 있을 때에는 공업적인 환 
경에서 민주적인 림이 역시 잘 일한다는것이다. 많은 경우에 프로그람작성자들은 연구경 
험 을 가진 콤퓨터 전문가들가운데 서 자원적 으로 제 기하여 들어 온 민주적 인 림 의 성 원들 
이다. 그러나 일단 과제가 해결하기 어려운 실현으로 귀착되게 되면 림은 다음장에서 서 
술되는 책임프로그람작성자림과 같은 보다 계층적인 형식으로서 재조직되여야 한다. 

4. 3. 고전적책 임프로그람작성자팀 방법 

그림 4-2 에 보여 준 6명으로 구성된 림을 고찰해 보자. 



그림 4-2. 세명의 를퓨터전문가들사이의 통신경로 
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15 개 의 2 인통신선로가 존재한다. 사실상 2, 3, 4, 5, 6 명 으로 구성 되 는 그룹들의 총 수 
는 57 개 이다. 이러한 통신선로의 다양성은 그림 4-2 에서와 같이 구성된 6 명으로 이루어 
진 림 이 36 명 이 1 개 월동안 수행하는 작업 을 6 개 월동안에 수행할수 없는 리유로 된 다. 즉 
둘 또는 그이상의 림성원들이 한번에 모여서 토론 하는데 많은 시간이 걸리게 된다. 그림 
4-3 에서 보여 준 6 명으로 구성된 림에 대하여 고찰해 보자. 거기에는 6 명의 프로그람 
작성자들이 있지만 통신선로는 5 개만 있다. 



그림 4-3. 고전적 책 임 프로그람작성 자림 의 구조 


이 것은 지금 책 임 프로그람작성 자 ( c / n ’ e //> ragrawmer ) 림 이 라는 용어의 리 면에 놓여 있 
는 기 초적 인 개 념 으로 된 다. 이 와 련관된 착상을 브룩스가 계 기하였 는데 그는 수술을 지 
도하는 책임의사를 류추하였다 [Brook 1975]. 책임의사는 다른 의사들과 마취사，여러 간 
호원들의 조력을 받는다. 이 밖에 필요한 경우 심장전문의사나 콩괄전문의사들과 갈은 다 
른 부분의 전문가들을 리용한다. 이러한 류추는 책임프로그람작성자림에 대한 두개의 중 
요한 측면을 강조하고 있 다. 첫번째 는 전문화 (■ speda / feaft ’ cw ) 이 다. 즉 림 의 매 성 원들을 자 
기 가 숙련된 그러 한 과제 들만 수행 한다. 두번째 는 계 층성 ( Werarc 切)이 다. 즉 책 임 의 사는 
림의 모든 성원들의 행동을 지휘하며 수술의 모든 측면에 대 하여 책 임을 진다. 

책 임 프로그람작성 자림의 개 념은 밀스 ( Mills ) 에 의 해서 형식 화되 였다 [ Baker , 1972]. 약 
30 년전에 베 이 커 가 서 술한 고전적책 임프로그람작성 자림 을 그림 4-3 에 보여 주었 다. 그것 
은 책 임 프로그람작성 자대 리, 프로그람작성 림서기，한명 부터 세명 까지 의 프로그람작성 자들 
의 방조를 받는 책임프로그람작성자로 구성되여 있다. 필요할 때 림은 법률이나 재정적 
인 사업 또는 조작체계명령을 해당한 그 시대의 대형콤퓨터에 보내주는데 리용되는 일감 
조종언어 ( JCL ) 명 령 과 같은 다른 령역의 전문가들로부터 방조를 받게 된다. 책 임 프로그람 
작성 자는 성공적 인 관리 자인 동시 에 구성 방식설계와 중요하거 나 복잡한 코드부분들을 
작성한 고도로 숙련된 프로그람작성 자이기 도 하였 다. 다른 림 성 원들은 책 임 프로그람작성 
자의 지도밑에 상세설계와 코드작성에 종사한다. 그림 4-3 에서 보여 준바와 같이 프로그람 
작성 자들사이 에는 통신선로가 없다. 즉 모든 대 화적 문제 들은 책 임 프로그람작성 자에 의해서 
조종된다. 마지 막으로 책 임프로그람작성 자는 다른 림 성 원들의 작업 을 검 토한다. 왜 냐하면 
책임프로그람작성자는 개인적으로 코드의 모든 행들에 대하여 책임을 지고 있기때문이다. 

그러 나 책 임프로그람작성 자도 사람인만큼 앓을수도 있 고 사고가 날수도 있 으며 직 업 
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이 변경될수도 있기때문에 책임프로그람작성자대리의 지위가 필요하게 된다. 따라서 책 
임프로그람작성 자대 리 는 모든 측면에 서 책 임프로그람작성 자만큼 자격 이 충분해 야 하며 
프로젝트에 대 하여 많은것을 알고 있어 야 한다. 이 밖에 책 임프로그람작성 자가 구성 방식 
설계 에 집중할수 있도록 하기 위 하여 책 임 프로그람작성 자대 리 는 검 은통시험 실례 계 획 작성 
(14.7) 과 설 계 공정 과는 촉립 인 다른 과제 들을 수행하게 된 다. 

서기라는 단어는 많은 의미를 가지고 있다. 서기는 전화를 받거나 편지를 쓰는 등의 
업무를 수행함으로써 책임자의 바쁜 사업을 도와 준다. 그러나 국가적 인물들에 대하여 
생각할 때 에는 서기를 고급사무원들중의 한 성 원으로 볼수 있다. 프로그람작성 림서기 는 
서 기일을 겸 임하는 조수인것 이 아니 라 고도로 숙련되 고 높은 보수를 받는 책 임프로그람 
작성 자림 의 중심 인물로 된다. 프로그람작성 림서기 는 프로젝 트제 품서고와 프로젝 트의 문서 
를 유지 정 비 할 책 임 을 지 고 있 다. 여 기 에 는 또한 원 천 코드목록작성 과 JCL , 시 험 자료들이 
포함된다. 프로그람작성 자는 자기들이 작성한 원천코드를 서기 에게 주는데 서 기는 그것 
을 기계가독형식으로 변환하고 콤파일, 련결, 적재, 실행하며 시험실례들을 실행할 책임 
을 지게 된다. 따라서 프로그람작성자는 프로그람작성이외의 다른 일은 하지 않는다. 기타 
다른 모든 측면의 작업 은 프로그람작성 림서 기 가 조종한다(프로그람작성 림서기 는 프로젝 트 
제품생산서 고를 유지 관리 하기때 문에 일부 기 업체 들에서는 그들을 사서 라고 부른다.). 

여 기서 서 술된 내 용들은 밀스와 베 이 커 가 내 놓은 착상이라는것 을 상기하자. 19기년 
까지 거 슬러 올라 가보면 그때 는 아직 도 착공기 가 널 리 리용되 고 있 었다. 코드작성 은 오 
늘 더는 그런 방법으로 진행되지 않는다. 이제는 프로그람작성자가 말단이나 작업콤퓨터 
상에 서 코드를 입 력 하고 편집 하고 시 험하는 등의 일 을 한다. 현대 의 고전적책 임프로그람 
작성 자림 에 대 해 서 는 4.4 에 서 서 술한다. 

4. 3. 1. 뉴욕타임스프로젝트 

책 임프로그람작성자림개념은 19기년에 IBM 회사가 뉴욕타임스의 신문기사자료철 
(《 자료부》)을 자동화하기 위하여 처 음으로 리용하였 다. 신문기 사파일 에 는 뉴욕타임스와 
다른 출판사들에 서 출판한 개 괄자료들과 전체 기 사들이 포함되 여 있 다. 보고서작성 자와 
편집부의 기타 성원들은 이 정보창고를 참고원천으로서 리용한다. 

이 프로젝 트의 실상은 사람들을 몹시 놀라게 하고 있 다. 실례 로 8만 3천여개 의 코드 
행 ( LOC ) 이 11명 의 1년동안의 노력 에 맞먹 는 22개 월 동안에 작성되 였 다. 첫 해후에 다만 
12, OOOLOC 로 구성 된 파일 관리 체 계 가 작성되 였 다. 대 부분의 코드는 마지 막 6개 월 동안에 
작성되 였 다. 첫 5주동안의 인수시 험 기 간에 는 다만 21개 의 오유가 발견되 였 다. 그이후의 
25개 오유는 제품이 가동한 첫해에 발견되였다. 원리적으로 프로그람작성자들은 평균 하 
나의 오유를 발견하며 한사람당 1년에 10,000 LOC 의 코드를 작성한다. 파일유지정비체계 
는 코드작성 이 완성 된 다음 한주일후에 배 포되 여 간단한 오유가 발견되 기 전까지 20개 월 
동안 동작하였 다. PL /1 에 서 보통 2 W 〜400행 에 달하는 부분프로그람의 거 의 절 반이 첫번 
째의 콤파일에서 정정되였다 [ Baker , 1972]. 
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그러나 이러한 공상적인 성공을 이록한 다음에도 책임프로그람작성자림개념에 대한 
그 어떤 명백한 요청은 제기되지 않았다. 많은 성공적인 프로젝트들이 책임프로그람작성 
자림 을 리 용하여 개 발되 였으나 그것은 뉴욕타임스프로젝트에서 처 럼 그렇게 인상적 이지는 
못했다. 무엇때문에 뉴욕타임스프로젝트가 그처럼 성공적인가? 무엇때문에 다른 프로 
젝트들에서는 류사한 결과가 얻 어 지지 않는가? 

그 첫번째 리유는 그것 이 IBM 의 명성 과 관련된 프로젝 트였다는것 이 다. 그것은 IBM 
에서 개발한 언어인 PL /1 에 있어서 처음으로 되는 실제적인 시험이였다. 뛰여 난 쏘프 
트웨어 전문가들에 게 잘 알려 진 IBM 은 자기 부문에서 가장 우수하다고 할수 있는 사람 
들을 망라하여 림 을 구성하였 다. 둘째 로 기 술적후원 이 아주 강했 다. PL /1 콤파일 러작성 자 
들은 가능한 모든 방법으로 프로그람작성자들을 직접 방조하였다. 그리고 JCL 전문가들은 
일 감조종언어 로써 방조하였 다. 세번째 리유는 책 임프로그람작성 자 에 프. 테리 베 이 커 의 
우수한 전문지식에 있다. 그는 현재 최고급프로그람작성자라고 불리우고 있다. 여기서 최 
고급프로그람작성자는 보통 훌륭한 프로그람작성자들에 비하여 4배 또는 5배의 결과를 
내놓을수 있는 프로그람작성 자들이 다. 이 밖에 메 이커는 뛰 여 난 관리 자，책 임자였으며 그 
의 기능과 열정, 성격은 프로젝트의 성공의 비결로 되였다. 

만일 책 임프로그람작성 자가 충분한 자격 을 가지 고 있 다면 책 임프로그람작성 자림조직 
은 잘 운영된다. 비록 뉴욕타임스프로젝트에서 이륙한 주목할만한 성과는 되풀이되지는 
않았지만 많은 프로젝 트들에 책 임프로그람작성 자방법 의 변종들이 리용되 였 다. 이 방법 의 
변종이 리 용된 리유는 문헌 [ Baker , 1972] 에 서 술된바와 같이 고전적책 임프로그람작성 자 
림이 많은 면에서 비현실적이기때문이다. 

4. 3. 2. 고전적 책임 프로그람작성자팀 방법의 비현실성 

프로그람작성 자와 성 공적 인 경 영 자의 결 합체 인 책 임 프로그람작성 자를 고찰하자. 이 러 
한 사람들은 찾아 보기 힘들다. 즉 성공적 인 관리측면은 물론 고도로 숙련되지 않을수 있 
는데 책 임프로그람작성자의 업무사항들은 이 두가지 능력을 모두 요구한다. 고도로 숙련된 
프로그람작성자로서의 자질은 성공적 인 관리자로서의 자질과 차이가 있으며 따라서 책 임 
프로그람작성자를 찾아 낼 기회는 적다. 그러나 만일 책임프로그람작성자를 찾아 내기 힘 
들다면 책 임프로그람작성 자대 리를 찾아 내기는 더욱 힘들다. 결국 책 임프로그람작성자대 리 
는 책 임 프로그람작성 자만큼 훌륭하다고 생 각되 지 만 책 임 프로그람작성 자에 게 서 무엇 인가 
일어 나기를 기다리는 동안에는 뒤전에 앉아서 보다 낮은 로임을 받지 않으면 안된다. 고 
급프로그람작성 자나 고급관리 자들은 거의나 이 러한 역할을 수행 하기를 바라지 않는다. 

프로그람작성 림서기 역시 찾아 내기가 힘들다. 쏘프트웨 어전문가들은 문서작업 을 
하기 싫어 하는것으로 유명한데 프로그람작성림서기는 하루종일 아무것도 하지 않고 
문서작업이외에는 그 어떤 작업도 하지 않는것으로 생각하고 있다. 

이 리하여 베 이커가 주장한것과 같이 적 어도 책 임프로그람작성자림들은 실천적으로 
비현실적이다. 민주적인 림도 역시 다른 리유로 하여 비현실적이다. 더우기 두가지 림방 
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법들은 모두 실현단계 에서 120명은 물론 20명의 프로그람작성 자를 요구하는 제품조차 조 
종할수 없을것 갈다. 민주적 인 림 과 책 임프로그람작성 자림 의 우점 을 리용하여 보다 더 
큰 제 품이 실현될수 있도록 하는 프로그람작성 림 을 조직하는것 이 필요하다. 

4.4. 책임프로그람작성자팀과 민주적팀의 초월 

민주적인 림은 주요한 우점을 가지고 있다. 즉 오유를 찾는데서 긍정적인 태도를 가 
지 고 있다는것 이 다. 많은 기 업체들은 코드검 토 (6.2) 와 관련하여 잠재적 인 과오를 범하면 
서 책 임프로그람작성 자림 을 리용한다. 책 임프로그람작성 자는 코드의 모든 행 에 대 하여 
개인적으로 책임을 져야 하며 따라서 모든 코드를 검토하는 동안 참석해야 한다. 그러나 
책 임프로그람작성 자는 역 시 6장에 서 설명하게 되 는바와 같이 관리 자이 며 검 토는 그 어 떤 
성능평가에 리용되지 말아야 한다. 그리고 책임프로그람작성자 역시 림성원들에 대한 초 
기의 평가를 책임진 관리자이기때문에 그자신이 코드를 검토하는데 참가한다는것은 좋은 
방책으로 되지 않는다. 

이러한 모순으로부터의 출로는 책임프로그람작성자로부터 여러가지 관리상의 기능을 
떼여 내는것 이 다. 결국 아주 기능이 높은 프로그람작성자이면서도 성공적 인 관리자인 한 
명의 개별적인 사람을 찾아 내는것이 어렵다는것은 이미 앞에서 지적되였다. 대신에 책 
임프로그람작성자는 림활동의 기술적인 측면을 책임진 림책임자와 모든 비기술적인 관리 
상의 결심을 내리는데서 책임을 지는 림관리자 두명으로 교체되여야 한다. 결과적인 림 
의 구조를 그림 4-4 에 보여 주었다. 




그림 4-4. 현대 프로그람작성 자림 구조 


이러한 조직적인 구조가 종업원들이 한명의 관리자이외의 다른 사람들에게 보고하 
지 않는다는 관리상 원칙을 위반하지 않도록 하는것이 중요하다. 책임의 범위를 명백히 
밝혀 야 한다. 림책 임 자는 오직 기술적 인 관리 에 대 해서만 책 임을 진다. 이 리하여 예산작 
성과 법 률상 문제는 림 책 임 자가 조종하지 않으며 또한 성능평 가 역시 마찬가지 이 다. 다 
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른 한편 림책임자는 기술적인 문제점들에 대하여 혼자서 책임을 지고 있다. 그러므로 
림관리자는 제품이 4주안에 배포될것이라는 계약을 체결할 권리가 없다. 즉 그런 종류 
의 계약은 림책임자가 해야 한다. 림책임자는 자연이 모든 코드검토에 참가한다. 결국 
그는 코드의 모든 측면에 대하여 혼자서 책임을 진다. 동시에 림관리자에게는 검토가 
허 락되 지 않는다. 왜 냐하면 프로그람작성 자의 성 능평 가가 림관리 자의 기 능이기 때 문이 다. 
대 신에 림관리 자는 정 기적 으로 진행되 는 림회 의를 하는 동안에 모든 림성 원들의 기 술기 
능에 대하여 알게 된다. 

실현이 시작되기전에 림관리자와 림책임자의 책임이라고 볼수 있는 범위를 정확히 
확정하는것 이 중요하다. 실례 로 휴가문제를 고찰하자. 휴가가 비기술적 인 문제 이기때 문에 
림관리 자가 휴가신청 을 승인했는데 최 종기 한이 다가와서 림책 임 자가 휴가신청 을 거 부하 
는 그런 상황이 일 어 날수 있 다. 이 문제 와 련관된 문제 의 해 결 방도는 림관리 자와 림 책 
임자들이 모두 자기들의 책임이라고 생각하는 령역들에 주목하면서 더잘 관리할수 있도 
록 대책을 작성하는것 이 다. 

보다 더 큰 프로젝트에 대 해서 는 어떠한가? 이 에 대 한 방법 은 그림 4-5 에서 보여 준 
바와 같이 확장될수 있는데 여기서는 기술적이며 관리적인 조직구조를 보여 주고 있다. 
그리 고 비기 술적 인 측면도 류사하게 조직 화되 였 다. 

제품의 전반적인 실현은 프로젝트책임자의 의도에 따라 진행된다. 프로그람작성자는 
자기들의 림책 임 자에게 보고하고 림책 임자는 프로젝트책 임 자에게 보고한다. 지어 보다 
큰 제 품에 대 해서 는 보충적 인 준위 를 계 층적 으로 추가할수 있 다. 민주적림 과 책 임프로그 
람작성 자림들의 좋은 특성 들을 모두 살리 는 또 다른 방법 은 적 당한 곳에서 결심 채 택공정 
을 분산시키 는것 이 다. 결과적 인 통신선로를 그림 4-6 에 보여 주었 다. 

이러한 구조도식은 민주적방법이 적당한 그런 종류의 문제들에서 쓸모가 있다. 
즉 어 떤 연구환경 이 나 또는 문제 해 결을 위하여 어 려 운 문제 들이 협동적 인 성격 을 
떤 그룹호상작용을 요구할 때 마다 쓸모가 있 게 된다. 분산화에도 불구하고 준위사이 
의 화살표는 프로그람작성자들이 혼란에로 이끌어 갈수 있는 프로젝트책임자들에게 
지 시하도록 허 용하면서 여 전히 아래 로 향하고 있다. 그러 나 프로그람작성 자림 에 관 
한 문제, 프로그람작성림조직문제 나아가서 다른 모든 단계들에서의 림조직문제에 
대 해서는 그 어떤 해결책도 없다. 림 을 조직하는 최 량방도는 개 발해 야 할 제 품과 여 
러가지 림구조에 대 한 이전의 경 험, 기 업체책 임 자의 전도에 의존한다. 실례 로 고급 
관리 자측이 분산적 인 결심채 택 에 동의하지 않으면 그때는 실현되지 않는다. 그러 나 
유감스럽게도 쏘프트웨어개발림조직에 대해서는 많이 연구되지 않았으며 일반적으로 
수용할수 있는 대 부분의 연구들은 보통 쏘프트웨 어 개발림 에 대 한 연구가 아니 라 그 
룹의 움직 임 에 관한 연구에 기 초하고 있다. 림조직 에 관한 실험 적 인 결과들이 쏘프 
트웨 어산업 에 서 얻 어 지 기전에 는 특정 한 제품에 대 하여 최 량인 림 의 조직 을 결정 하 
기 가 쉽 지 않을것 이 다. 
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4. 5 . 동기 및 안정화팀 

림조직에 대한 또 다른 방법에는 Microsoft 에서 리용된 동기 및 안정화림방법이 있다 
[Cusumano and Selby , 1997]. Microsoft 는 큰 제품을 개발한다. 실례로 원도우즈 20 W 은 3 
천만개 이상의 행 을 가진 코드로 구성되 여 있으며 3천명 이 넘 는 프로그람작성 자들과 시 험 
자들에 의 해서 개발되였다 [Business Week Online , 1999]. 림 조직은 이러한 규모의 크기를 
가진 제 품을 성 공적 으로 개 발하기 위한 하나의 중요한 측면 으로 된다. 

동기 및 안정 화생 명 주기 모형 은 3.6 에 서 서 술되 였 다. 이 모형 이 성 공한것 은 기 본림 조 
직 방법의 결과이 다. 동기 및 안정 화모형 의 셋 또는 네개의 련속적 인 매 구조물들은 프로 
그람관리 자가 이 끌며 3~8명 의 개 발자들과 그들과 일 대 일 로 작업 을 진행하는 3~8명 의 
시 험 자들로 구성된 여 러개의 자그마한 병 렬림들에 의해서 구축된다. 림은 전반적 인 과제 
에 대 한 명세 서 를 받게 된다. 개 별적 인 림성 원들은 다음에 그 과제 들에서 자기 들의 몫을 
자유롭게 설계 하고 실현하게 된다. 이것 이 해커 에 의해서 일어 나는 혼란에로 재빨리 넘 
어 가지 않는 리유는 매 일 진행하는 동기 화단계 에 있 다. 즉 부분적 으로 완성 된 구성 요소 
는 매일 시험되고 수정된다. 이리하여 지어 매 사람들의 창조성과 자률성이 발휘된다고 
할지라도 개별적인 구성부분은 항상 함께 동작한다. 

한편 이러한 방법의 우점은 개별적인 프로그람작성자들이 어떤 민주적림의 하나의 
특성 인 창조적 이 고 혁 신적 인 사람으로 되 도록 고무한다는것 이 다. 다른 한편 매 일 진행하 
는 동기 화단계 는 수백명 의 개 발자들이 공동의 목적 을 위하여 책 임프로그람작성 자림 에 고 
유한 정보전달과 공동작용을 요구하지 않고 함께 일하고 있다는것을 담보한다(그림 4-3). 

마이크로쏘프트개발자들은 매우 적은 규칙을 준수하여야 하는데 그중의 하나는 그들 
이 일 별 동기 화를 보장하기 위하여 제 품자료기 지 에 자기 들의 코드를 넣 어 보관하는 시 간 
을 엄격히 준수해야 한다는것이다. 무수마노와 쎌비는 이것은 아이들에게 하루종일 그들 
이 하고 싶은 일을 할수 있으나 저녁 9시에는 잠을 자야 한다고 말해 주는것과 같다고 
보았다 [Cusumano and Selby , 1997]. 또 다른 하나의 규칙은 만일 개 발자들의 코드가 제품 
이 일별 동기 화를 위하여 콤파일되 는것을 막기 위 해서는 림의 나머지성 원들이 그날작업 
을 시 험 하고 오유검 사를 하고 수정할수 있도록 문제 가 즉시 수정 되 여 야 한다는것 이 다. 

동기 및 안정 화모형의 리용과 그와 련관된 림조직 이 기 타 다른 모든 기 업체들이 마 
이크로쏘프트와 같이 성공할수 있다는것을 담보해 줄것인가? 이것은 전혀 그렇지 않다. 
마이 크로쏘프트회 사는 동기 및 안정 화모형 이상의 수준에 있다. 마이 크로쏘프트회 사는 그 
룹적기 질을 가지 고 있는 뛰 여 난 관리 자들과 쏘프트웨 어개 발자들로 이 루어 진 기 업체 이 
다. 단순히 동기 및 안정화모형만을 리용하는것은 기업체를 또 다른 하나의 마이크로쏘 
프트회 사로 전환시 키 기는 기 적을 가져 오지 못할것 이 다. 동시 에 다른 기 업체들에서 리용 
하는 모형 들의 여 러 가지 특성 을 리용하는것 은 공정 을 개 선하도록 해 준다. 다른 한편 동 
기 및 안정화모형은 해커들의 그룹이 큰 제품을 개발하도록 하는 간단한 방법으로 된다 
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는것 이 제기되 였다. 앞부분의 마감에서 언급한바와 같이 최 량인 프로그람작성 자림조직과 
관련하여 결론을 끌어 내기전에 경험적인 자료가 필요하다. 

4. 6. 최종적프로그람작성팀 

3.5 에서 최 종적 프로그람작성 림 에 대 하여 개 관하였 다 [ Beck , 1999]. 이 절 에서 최 종적 
프로그람작성 ( XP ) 이 리용될 때 림이 어떻게 조직되는가를 서술한다. 

자의 약간 례외적인 특성은 모든 코드가 하나의 콤퓨터를 공유하고 있는 두명의 프 
로그람작성 자들로 구성된 림 에 의해서 작성된다는것 이 다. 이것 을 2인프로그람작성 이라고 
부론다 [ Williams , Kessler , Cunningham , and Jeffries , 2000]. 여 러 가지 리 유로 하여 이 방법 
을 리용한다. 

1. 3.5 에서 설명한바와 같이 프로그람작성 자들은 먼저 시 험 실례 를 작성 하고 그다음에 
는 코드(과제 )의 해 당한 부분을 실 현 한다. 6.2 에 서 설 명한바와 같이 프로그람작성 자 
들이 자기 들의 코드를 시 험하도록 하는것 은 좋은 방책 이 아니 다. 재는 림 의 한 프 
로그람작성자가 한 과제에 대한 시험실례를 작성하고 다른 프로그람작성자가 그와 
결 합하여 이 시 험실례 들을 리 용하여 코드를 실현하도록 함으로써 이 문제 를 에돌 
아 가게 한다. 

2. 보다 습관적 인 생 명 주기모형 에서는 개 발자들이 어 떤 프로젝 트를 포기할 때 그 
개 발자들이 축적한 모든 지식도 역시 버 려 진다. 특히는 개 발자들이 작업 하고 
있 는 쏘프트웨어 는 아직 문서 로 작성되 여 있 지 않을수도 있 고 처 음부터 다사 
개 발하여 야 할수도 된 다. 대 조적 으로 만일 2인프로그람작성 림 의 한명 이 떠나가 
면 다른 성 원은 새 로운 2인프로그람작성 자와 함께 쏘프트웨어의 같은 부분을 
계속 개발할수 있는 충분히 지식을 가지고 있다. 더우기 시험실례들은 오유를 
밝히는데 도움을 주며 새림은 무분별한 변경을 만듦으로써 쏘프트웨어를 손상 
시키게 될것이다. 

3. 2명이 밀접히 결합되여 일하는것은 경험이 어린 쏘프트웨어전문가들로 하여금 
더 경험 있는 림성원들의 기능을 획득할수 있게 한다. 

4. 3.5 에 서 언급한바와 같이 여 러 가지 XP 2인 림들이 리용하는 모든 콤퓨터 들은 큰 
방가운데 함께 놓여 야 한다. 이것은 주관이 없는 림들의 공정적 인 특성 인 코드에 
대한 그룹소유를 촉발시 킨다 (4.2). 

이 리하여 두명 의 프로그람작성 자들이 갈은 콤퓨터 상에 서 함께 작업할데 대 한 착상이 
약간 례외적인것 같다 하더라도 실천에서는 뚜렷한 우월성을 가진다. 이것으로 림조직에 
대 한 론의는 결속된다. 여 러 가지 류형의 림조직들의 비교를 그림 4-7 에 주었다. 
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관리 에 관한 기 사는 Communications of the ACM 1993 년 10 월호에서 찾아 볼수 있 
다. 문헌 [ Royce , 1998] 의 11 장은 림 성 원들이 놀게 되 는 역 할에 대 한 유용한 정 보 
들을 포함하고 있다. 

동기 및 안정화림은 문헌 [Cusumano and Selby , 199 기에서는 개괄하여 주었고 문 
헌 [Cusumano and Selby , 1995] 에서 자세히 서술하였다. 동기 및 안정화림 에 대 한 
지 식은 문헌 [ McConnell , 1996] 에 서 얻 을수 있 다. 최 종적 프로그람작성 은 [ Beck , 1999] 
와 [ Beck , 2000] 에 서 술되 여 있다. 문헌 [ Williams , Kessler , Cunningham , and Jeffries , 
200 이은 최 종적프로그람작성 의 한 구성 부분인 2인프로그람작성 에 대 한 실험 을 서 술 
하고 있다. 


문 제 

4.1. 로임지 불계산프로젝 트를 개 발하는 림 을 어 떻게 조직하겠는가? 최 첨 단군사통신쏘 
프트웨어 를 개발하기 위한 림 은 어 떻 게 조직하겠는가? 대 답을 설 명하시오. 

4.2. 당신은 방금 새로운 쏘프트웨어회사를 개설하였다. 모든 종업원들은 최근에 단 
과대학을 졸업하였 다. 그들은 처 음으로 프로그람을 작성하게 된 다. 당신의 론리 에 서 민주 
적개발림을 실현할수 있는가? 그렇 다면 어떻게 결합하겠는가? 

4.3. 어떤 대학생 프로 그람작성림은 민주적 림으로 조직된다. 림에 있는 대학생들에 대 
하여 무엇을 추론할수 있는가? 

4.4. 어 떤 대 학생프로그람작성 림 은 책 임프로그람작성 자림 으로 조직 된 다. 림 에 있는 
대 학생들에 대 하여 무엇을 추론할수 있는가? 

4.5. 큰 쏘프트웨 어 회 사안에 있 는 두개 의 서 로 다른 림 T 01 과 T 02 를 비 교하기 위하 
여 다음의 실험 을 제 기한다. 같은 쏘프트웨 어제품이 두개 의 서 로 다른 림 에 의하여 개 발 
되는데 하나는 T 01 에 따라 조직되고 다른 하나는 T 02 에 따라 조직된다. 회사는 매 림 이 
제 품을 개 발하는데 약 18 개 월 이 걸릴것 이 라고 평 가하였다. 이 실험 이 왜 비현실적 이며 
의 미 있는 결과를 주지 못하는가에 관한 세 가지 리유를 드시 오. 

4.6. 왜 최 종적프로그람작성 림 이 하나의 콤퓨터 를 공유하는가? 

4.7. 당신은 동기 및 안정 화림 을 리용하는 회 사에 서 일 하고 싶은가? 당신의 대 답을 
정 당화하시 오. 

4.8. (과정 안상 목표) 부록 1에 있는 브로드랜 즈지 역 아동병 원제 품을 개 발하기 위 하여 
서는 어떤 형태의 림조직이 적합한가? 

4.9. (쏘프 트웨 어 공학독본) 교원 이 문헌 [Cusumano and Selby , 199 刀의 복제 본을 배 포 
할것 이 다. 어 떤 형 식의 책 임프로그람작성 자림 을 리용하고 있는 회 사에 동기 및 안정 화림 
을 어 떻게 도입하겠는가? 
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제 5 장. 거래되고 있는 도구 


쏘프트웨어공학자들은 두가지 류형의 도구를 요구한다. 첫째로 계단식세련과 비용 
대 리 득분석 과 같은 쏘프트웨 어 개 발에 서 리 용되 는 분석 도구들이 다. 둘째 로 쏘프트웨 어 도 
구 즉 쏘프트웨 어를 개발하고 유지정 비하는데서 쏘프트웨 어공학자들의 림을 도와 주는 
제 품들이 있는데 이 것 들을 보통 CASE 도구라고 한다 ( CASE 는 를퓨터 지원프로그람공학의 
략어 이 다.). 이 장에 서 는 이 런 두가지 류형 의 거 래 도구를 론의한다. 즉 처 음에 는 리 론적 
도구를, 그다음에 는 쏘프트웨 어 ( CASE ) 도구를 론의한다. 계 단식 세 련 으로부터 시 작하자. 

5.1. 계단식세련 

계 단식세 련은 많은 쏘프트웨 어 공학기 법들의 기 초를 이 루고 있는 문제 해 결기 법 이 다. 
그것은《중요한 문제점들에 집중하기 위하여 세부들에 대한 결정은 가능한껏 뒤로 미룬 
다.》는 의미로서 정의될수 있다. 이 책을 읽어 나가는 과정에 볼수 있는바와 같이 계단 
식세련은 여러가지 명세작성기법，설계 및 실현기법, 지어 시험 및 통합기법의 기초를 이 
루고 있다. 계단식세련이 그렇게 중요하게 된 리유는 밀러의 법칙 [ Miller , 1956] 때문인데 
그것 은 한번에 사람은 기껏해 서 7±2개 의 토막들(정 보량들)에 집 중할수 있 다는것 을 말해 
준다. 

쏘프트웨 어 를 개 발할 때 에 제 기 되 는 문제 는 한번 에 7개 이 상의 토막들에 집 중해 야 한 
다는것 이 다. 실례 로 하나의 콜라스는 보통 7개보다 훨씬 더 많은 속성 과 방법 을 가지 고 
있 으며 의 뢰 자는 7개 이 상의 요구사항를 가지 고 있 다. 계 단식 세 련은 쏘프트웨 어공학자들 
로 하여금 현재의 개 발단계와 가장 관련 있는 7개의 토막들에 집중할수 있도륵 한다. 다 
음의 실례는 제품의 설계 단계 에서 어 떻게 계 단식세 련이 리용되는가를 설명 하고 있다. 

5. 1 • 1 • 계단식세련의 실례 

여기서 취급하는 실례는 많은 응용령역에 있는 공통적인 조작들인 련속적인 주파일 
들을 갱신하는것을 포함하고 있다는 점에서 거의 자명할수 있다. 진행중에 있는 문제가 
아니라 계단식세련에 집중할수 있도록 하기 위하여 이와 같은 잘 알려 진 실례가 심중히 
선택된다. 

월간 잡지 True Life Software Disasters 에 대 한 이름과 주소자료를 포함하고 있는 련속적 인 
주파일을 갱신하는 제품을 설계하시오. 여기에는 세가지 류형의 트랜잭션 즉 삽입，수정, 삭 
제 가 있는데 각각 트랜잭 션 1, 2, 3이 라고 한다. 이 리하여 트랜잭 션의 류형 은 다음과 같다. 

류형 1: INSERT (주파일에 대 한 새로운 신청 자) 

류형 2: MODIFY (현존 신청자기록) 
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류형 3: DELETE (현존 신청자기록) 


트랜잭션은 신청자의 이름에 대하여 자모순으로 정돈된다. 만일 주어 진 신청자에 대하여 
하나이상의 트랜잭션이 존재하면 그 신청건에 대한 트랜잭션은 변경전에 삽입이 진행되고 
삭제전에 변경이 진행되도록 정렬되였다. 

풀이 를 설 계하는데 서 첫 단계 는 그림 5-1 에 서 보여 주는바와 같이 입 력트랜잭 션에 
대 한 하나의 전형 적 인 파일 을 설 치하는것 이 다. 


트렌잭션의 형 

이 름 

주 소 

3 

Brown 


1 

Harris 

2 Oak Lane, Townsvill 

2 

Jones 

Box 345, Tarrytown 

3 

Jones 


1 

Smith 

1304 Elm Avenue, Oak City 


그림 5-1. 련속적 인 주파일에 대한 입력트랜잭션기록 

파일은 5 개의 기록 즉 DELETE Brown , INSERT Harris , MODIFY Jones , DELETE Jones , 
INSERT Smith 를 포함하고 있다(일단 동작과정에 같은 신청자에 대하여 변경과 삭제를 모 
두 진행할수 있다는것 은 일 반적 이 다.). 문제 는 그림 5-2 에 서 보여 주는바와 같이 표현된다. 



그림 5-2. 련속적인 주파일의 갱신 


두개 의 입 력파일 이 있 다. 즉 
1. 낡은 주파일 이름과 주소기록 




2. 트랜잭션파일 

그리 고 세개의 출력파일 이 있다. 즉 

3. 새 로운 주파일 이름과 주소기록 

4. 례외 보고서 

5. 개괄과 업무완료통보문 

설 계 과정 을 시 작하기 위하여 그림 5-3 에 서 보여 준바와 같이 첫 시 작위 치 는 하나의 
통 주파일 갱신이다. 이 통은 입력, 처리, 출력이라고 하는 세개의 통으로 분해될수 있다. 
처리가 기 록을 요구할 때 우리 는 바로 정 확한 시 간에 정 확한 기 록들을 생 성할수 있는 능 
력을 가지고 있다고 가정을 한다. 류사하게 우리는 정확한 시간에 정확한 기록을 정확한 
파일에 쓸수 있다. 따라서 기술은 입력과 출력측면을 따로 분리하고 처리에 집중하는것이 
다. 이 처리는 무엇인가? 그것의 사명을 결정하기 위하여 그림 5-4 에서 보여 준 실례를 
고찰하자. 



그림 5-3. 설계의 첫번째 세련 


트랜잭션파일 낡은 주파일 새 주파일 


3 Brown 


Abel 


Abel 

1 Harris 

Brown 

Harris 

2 Jones 

James 

James 

3 Jones 

Jones 

Smith 

1 Smith 

Smith 

Townsend 



Townsend 




례 외 보고서 
Smith 


그림 5-4. 트랜잭션파일, 낡은 주파일，새 주파일 그리고 례외보고서 

첫 트랜잭션기 륵 ( Brown ) 에 대 한 열쇠 를 첫 낡은 주파일기 록 ( Abel ) 에 대 한 열쇠 와 
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비교한다. Brown 이 Abel 다음에 오기 때문에 Abel 기록은 새로운 주파일에 써 주고 다음의 
낡은 주파일기 록 ( Brown ) 이 읽 어 진다. 이 경 우에 트랜잭 션기 록에 대 한 열쇠 는 낡은 주 
파일 기록에 대한 열쇠와 정합되고 트랜잭션류형이 3( DELETE ) 이기 때문에 Brown 기록은 
삭제 되 여 야 한다. 이 것은 Brown 기 록을 새 로운 주파일 에 복사시 키 지 않음으로써 실현된 
다. 다음 트랜잭션기록 ( Harris ) 과 낡은 주파일기록 ( James ) 이 읽어 지고 그것들의 개개의 
완충기들에 Brown 기록을 덧쓰기 한다. Harris 는 James 앞에 있고 따라서 새로운 주파일에 
삽입된다. 다음 트랜잭션 기록 ( Jones ) 이 읽어 진 다. Jones 는 James 다음에 있기 때문에 
James 기록은 새로운 주파일에 씌여 지게 되고 다음 낡은 주파일기록이 읽어 진다. 즉 
이것이 Jones 이다. 트랜잭션파일에서 볼수 있는바와 같이 Jones 기록은 변경되고 그다음 
삭제 되 며 따라서 다음 트랜잭 션기 록 ( Sm 池)과 다음 낡은 주파일기 록(역 시 Sm 池)이 읽 
어 진다. 다행 히 도 트랜 잭 션류형 이 l ( INSERT ) 이 지 만 Smith 는 이 미 주파일 에 있다. 따 
라서 자료에 는 일정한 종류의 오유가 존재하며 Smkh 기 록은 례외 보고서 에 씌 여 진다. 
더 정확히 보기 위하여 Smith 트랜잭션기록은 례외보고서에 씌여지고 Smith 낡은 주파 
일기 록은 새 로운 주파일 에 씌 여 진 다. 

이제 는 처리에 대 하여 리해 되 기때 문에 그것은 그림 5-5 에서처 럼 표현될수 있다. 


트랜잭션기록건 = 낡은 기본 
파일 기록건 

1. INSERT : 오유통보문을 인쇄한다. 

2. MODIFY : 주파일 기 록을 변경한다. 

3. DELETE : * 주파일 기 록을 삭제한다. 

트랜잭션기록건 > 낡은 기본 
파일 기록건 

새 주파일에 낡은 주파일기록을 복사한다. 

트랜잭션기록건 < 낡은 기본 
파일 기록건 

1. INSERT : 새 주파일에 트랜잭션 
기록을 써 넣는다. 

2. MODIFY : 오유통보문을 인쇄한다. 

3. DELETE : 오유통보문을 인쇄 한다. 


* 주파일기록의 삭제'聲 새 주파일기록에 기록을 복사하지 않고 실현된다. 


그림 5-5. 처리의 도식적인 표현 

다음으로 그림 5-3 의 처리통이 그림 5-6 의 두번째 세련의 결과로 세련되게 된다. 
입력과 출력 통에 점선을 친것은 입력과 출력을 조종하는 방법에 대한 결정이 다음 
세 련까지 연기되 였 다는것 을 의 미한다. 그림 에 서 나머 지 부분은 처리에 대 한 흐름도표이고 
또는 오히려 앞선 흐름도표에 대한 초기의 세련으로 된다. 이미 강조한바와 같이 입력과 
출력은 연기된다. 또한 파일의 끝조건에 대하여서는 대책이 없고 오유조건에 맞다들릴 
때 무엇을 하여야 하는가 하는것이 아직 명시되지 않았다. 계단식세련의 우점은 이러한 
문제 들과 류사한 문제 들이 이 후 세 련과정 에 해 결 될 수 있 다는것 이 다. 
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L 림 5-7 을 초래하는 그림 5-6 의 입력과 출력 통을 세 련 
여전히 조종되지 않았거나 또는 일감완료통보문이 아직 
-은 이 후의 반복에 서 수행 될수 있다. 그러 나 결정 적 인 
본오유를 가지 고 있 다는것 이 다. 이것을 보기 위하여 그 
찰하자. 이때 현재의 트랜잭션은 2Jones 즉 Jones 가 변 
록은 Jones 이 다. 

호계에서 트랜잭션기록에 대한 열쇠는 낡은 주파일기내 
왼쪽에 있는 통로는 트랜잭션류형시험 결정통에로 따라 
I MODIFY 이기때문에 낡은 주파일기록은 변경되여 새: 
음의 트랜잭션기록이 읽어 진다. 이 기록은 3Jones 이다. 
된 Jones 기록은 이미 새로운 주파일에 씌여 졌다. 독자 
의도적으로 제시되였는가고 이상하게 여길수도 있다. 

1•음단계 에 로 넘 어 가기전에 매 개의 성 공적 인 세 련에 e 
필요하다는것 이 다. 만일 특정한 세 련이 오유로 되 여 u 













히 개발된 다음에 조종된다. 명백하게 파일의 열기와 닫기를 진행하지 않고서는 제품을 
실행할수 없다. 그러나 여기서 중요한것은 파일열기, 파일닫기와 같은 세부들이 조종되는 
설계공정에서의 단계이다. 설계가 진행되고 있는 동안은 설계가들이 한번에 집중할수 있 
는 7개정 도의 토막들은 파일열기 와 닫기 와 같은 세 부들을 포함하지 말아야 한다. 즉 파 
일열기 와 닫기는 설계 그자체 에서는 아무것도 하지 말아야 하며 순전히 설계의 부분으로 
되는 실현세부로 된다. 그러 나 후의 세 련에서는 파일열기 와 닫기 가 사활적 인것 으로 된 
다. 달리 말하면 계단식세련은 그 단계안에서 해결되여야 할 여러가지 문제들의 우선권을 
설정 하기 위한 하나의 기 법 으로 고찰될수 있다. 계 단식세 련은 임의 의 한 순간에 _義_ 
이상의 토막들을 조종하지 않고서도 매 문제가 풀릴수 있으며 그 매개는 적당한 시간에 
풀린다는것을 담보한다. 

용어 계 단식 세 련(成£夕 1 ^£ refinemenf ) 은 워 스 [ Wirth ，1971] 에 의 하여 처 음으로 도입 되 
였다. 앞의 실례에서 계단식세련은 흐름도 표에 적용되였다. 반면에 워스는이 기법을 의 
사코드를 작성하는데 응용하였 다. 계 단식 세 련 이 적 용되 는 특정한 표현은 중요치 않다. 즉 
계 단식세 련은 쏘프트웨 어개 발의 매 단계 에 서 거 의 모든 표현과 함께 리 용될 수 있는 일 반 
적 인 기법으로 된다. 

계 단식세 련의 능력 은 쏘프트웨 어공학자들이 현재의 개 발단계(앞의 실례 에서 설계단 
계)에서의 관련 있는 측면들에 집중하도록 도와 주며 비록 전면적인 구조도식에서 본질 
적 이 라고 하더 라도 고려할 필요가 없는 세 부들을 무시하도록 도와 주는것 이 다. 사실상 
이러한 세부들은 늦게까지 무시되여야 한다. 문제전체를 중요성에서 본질적으로 등가인 
부분문제 들로 분해하는 분할정 복기법 과는 달리 계 단식세 련에 서는 문제 의 특수한 측면 이 
가지는 중요성 이 매 세 련에서 변화되 게 된다. 초기 에는 어 떤 특정한 문제 가 련관이 없을 
수도 있지만 후에는 같은 론점들이 결정적으로 중요하게 될것이다. 계단식세련에서의 난 
관은 현재의 세련에서 어떤 문제점들은 조종되여야 하며 어떤 문제점들이 이후의 세련으 
로 미루어 야 하는가를 결정하는것 이 다. 계 단식세 련과 같이 비용 대 리득분석은 쏘프트 
웨 어생명주기전반에서 리용된 또 하나의 근본적 이며 리론적 인 쏘프트웨 어공학기 법 이 다. 
이 기 법은 다음절에서 설명한다. 

5. 2. 비용 대 리득분석 

어떤 가능한 작용과정이 유익한가를 결정하는 하나의 방법은 계획된 장래비용과 타 
산된 장래 리득을 비교하는것 이 다. 이것을 비용 대 리득분석分?/ ana 公 w 이이 라고 한 
다. 를퓨터와 관련한 범위에서 비용 대 리득분석의 실례로 1965년에 크래그중앙전기회사 
( KCEC ; Krag Central Electric 가 계산서 작성체계의 공퓨터 화실현문제를 어떻게 

결정하였는가를 고찰해 보자. 계 산서작성 은 KCEC 손님 들에 게 두달에 한번씩 계 산서 를 우 
편발송해 주는 80여명의 사무원들에 의해서 수동적 으로 진행 되 고 있었다. 콤퓨터화를 실 
현 하기 위하여 KCEC 는 착공카드나 자기레 프에 입 력 자료를 기 록하기 위한 자료획 득설 비 
를 비 롯하여 필 요한 쏘프트웨어 와 하드웨 어 를 사거 나 임 대하여 야 했다. 

를퓨터화의 한가지 우월성 은 계 산서 가 두달에 한번 이 아니 라 매 달 발송될 수 있 으며 
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따라서 회 사의 현금수입 이 상당히 개 선될 수 있 다는것 이 다. 더우기 80여 명 의 계 산서작성 
사무원들이 11명 의 자료작성사무원들로 교체되 게 된 다. 로임절 약은 157만 5천딸라로 평 
가되였고 개선된 현금수입은 87만 5천딸라의 가치를 가지게 되 였다. 따라서 전체적 인 리 
득은 245만딸라로 평가되였다. 다른 한편 높은 로임을 받는 콤퓨터전문가들이 지도하는 
완전한 자료처 리 부서 를 설 치하여 야 하였 다. 7년 이 지 나서 비 용은 다음과 같이 평 가되 였 
다. 유지 정 비 를 포함하여 쏘프트웨 어 와 하드웨 어 의 가격 은 125만딸라로 평 가되 였 다. 첫 해 
에는 35만딸라의 전환비용이 들었고 새 체계를 손님들에게 설명되는데 든 비용은 추가적 
으로 12만5천딸라로 평 가되 였 다. 전체 가격 은 172만 5천딸라로 평 가되 였 고 평 가된 리득 
보다도 약 75만딸라가 더 적 었 다. KCEC 는 즉시 에 콤퓨터화를 진행 하기 로 결정하였 다. 

비용 대 리득분석은 언제나 늘 단순한것은 아니다. 한편 어떤 관리고문은 로임절약 
을 타산할수 있으며 부기원도 현금수입에서의 개선을 계획할수 있다. 그리고 순리득금 
[ Yourdon , 1989] 은 화폐 가치 의 변경 을 조종하는데 리용될 수 있으며 쏘프트웨 어공학고문은 
하드웨 어 와 쏘 프트웨 어 의 가격 과 그리 고 그것 들로 전환시키 는데 드는 가격 을 타산할수 
있다. 그러 나 콤퓨터화에 적 응하기 위하여 노력하는 손님 들을 위하여 지 출되 는 비 용을 
어 떻 게 결 정 하겠는가? 또는 홍역 에 대 처 하여 전체 주민들을 접 종시 키 는것 으로부터 얻 는 
리득은 어 떻게 측정하겠는가? 

중요한것은 명백한 리득은 측정하기가 쉽지만 막연한 리득은 적접 정량화하기가 힘 
들다는것 이 다. 막연한 리득에 대 하여 딸라가격 을 부여하는 현실적 인 방도는 가설 
( assumption ) 을 세우는것이다. 이러한 가설들은 언제나 결과적인 리득타산과 결합되여 언 
급되 여 야 한다. 결국 관리 자들은 결심 을 해 야 한다. 만일 리용가능한 자료가 없다면 이 러 
한 자료로부터 일반적으로 결정되는 가설확립은 환경에 기초하여 수행될수 있는 가설이 
가장 좋은 방도로 된다. 이러한 방법은 만일 자료와 기초를 이루고 있는가를 검토하는 
누군가가 더 좋은 가설을 제 기할수 있다면 더 좋은 자료가 생성되 고 그와 관련한 막연한 
리득이 보다 더 정확하게 계산될수 있다는 우점이 있다. 그러한 기법은 막연한 가격을 
결 정하는데 리용될 수 있 다. 

비용 대 리득분석은 손님들이 자기의 업무를 를퓨터화하는가, 그렇게 한다면 어떤 
방법으로 하겠는가를 결정하는데서 중요한 기법으로 되고 있다. 여러가지 변화된 전략들 
에 대하여 가격과 리득이 비교된다. 실례로 약품시험결과를 보관하는 제품은 보통의 파 
일과 여 러 가지 자료기지관리체 계 를 비 롯하여 여 러 가지 방법 으로 실현될수 있다. 매 가능 
한 전략에 대하여 가격과 리득을 계산하고 가격과 리득차가 최대인것들중에서 하나를 최 
량인 전략으로 선택한다. 

이 장에 서 서 술한 마지 막 리 론적 인 도구는 쏘프트웨 어척 도이 다. 

5. 3. 쏘프트웨어의 척도 

2.11 에서 서술한바와 같이 측정(또는 척도)이 없으면 문제점들을 걷잡을수 없게 쏘프 
트웨어개발공정에서 신속하게 이러한 문제점들을 발견해 낼수 없다. 이리하여 척도는 가 
능한 잠재적인 문제들에 대하여 신속하게 경고를 주는 체계로써 쓰일수 있다. 실례로 코 
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드의 행 들은 제 품의 크기 를 측정하는 방도의 하나로 된다 (9.2.1). 만일 LOC 측정 이 규칙 적 
인 간격으로 진행되면 그것은 프로젝트개발이 얼마나 빨리 진행되고 있는가를 측정할수 
있게 해 준다. 이 밖에 코드 1,000행 당 결 함(오유)의 수는 쏘프트웨어 의 품질 에 대 한 측정 
으로 된다. 결국 프로그람작성자가 한달동안에 2,000행이 되는 코드를 모순이 없게 작성 
하였지만 그 절반은 접수할수 없기때문에 버려야 한다면 조금밖에 리용되지 않게 된다. 
따라서 LOC 하나로서는 그리 중요한 척도로 되지 않는다. 

일 단 제품이 의뢰 자의 를퓨터 에 설치되면 오유들사이의 평균시간과 같은 척도는 관 
리 자측에 그 믿음성 에 대 하여 지적해 준다. 만일 어떤 제품이 매 일 실패하면 그 품질은 
실패가 없이 평균적으로 9개월동안 동작한 류사한 제품의 품질보다 더 낮다. 

정 확한 척 도는 쏘프트웨 어개 발공정 전반에 걸 쳐 리용될수 있다. 실례 로 매 단계 에 대 
하여 한사람당 한달동안에 들인 노력 을 측정할수 있다. 직 원이동비률은 또 하나의 중요 
한 척도로 된다. 새로 온 종업원은 프로젝트와 관련한 일들에 익숙하는데 시간이 들기때 
문에 현재의 프로젝트에 불리한 영향을 준다 (4.1). 이 밖에 새로 온 종업 원은 쏘프트웨 어 
개 발공정의 여 러 측면에서 교육을 받아야 할수 있다. 즉 만일 새로 온 종업 원이 교체된 
개 별적 인 사람들보다도 쏘프트웨 어공학에 대 해서 더 적 게 교육을 받았다면 그때 는 개 발 
공정전체 가 애 로를 느끼 게 된 다. 물론 가격 은 역 시 개 발공정전반에 대 하여 계 속 관리되 
여야 할 필수적인 척도이다. 

이 책에서는 여러가지 서로 다른 척도들이 서술된다. 일부 척도들은 제품의 척도 
{product me / r / c 功이 다. 즉 그것 들은 제 품의 크기 라든가 제 품의 믿 음성 과 같은 제 품 그자체 
에 관한 일부 측면을 측정한다. 대비적으로 다른 척도들은 공정척도(厂 racew me / nc 功이다. 
즉 이러한 척도들은 개발자들로 하여금 쏘프트웨어개발공정에 대한 정보를 도출하도록 
하는데 리용된다. 이런 종류의 전형적 인 척도는 개발기간에서의 오유발견효률 즉 제품이 
개 발리용되 는 전 기 간에 걸 쳐 제 품에 서 발견되 는 전체 오유개 수에 대 한 개 발기 간에 발견 
된 오유개 수의 비률이다. 

많은 척도들은 주어 진 단계 에 특정한것들이 다. 실례 로 코드의 행들은 실현이 시 작 
되 기 전에 는 리용될수 없다. 그리 고 명세 서 를 검 토하는데 서 시 간당 발견된 오유개 수는 다 
만 명 세작성단계 와만 관련된 다. 쏘프트웨 어개 발공정 의 여 러 단계 들을 서 술한 다음의 장 
들에서는 그 장들과 관련된 척도들을 론의하고 있다. 

비 용은 척 도값을 계 산하는데 필 요한 자료를 수집하는데 포함된 다. 지 어 자료수집 이 
완전히 자동화되 면 요구되 는 정 보를 축적하는 CASE 도구 (5.4) 가 무료가 아니 며 그 도구로 
부터 나온 결 과들을 해 석하는데 노력 이 든다. 수백개 (수천 개 는 아니 다.:)의 서 로 다른 척 도 
가 앞으로 제기된다는것을 념두에 두면 한가지 명백한 문제는 쏘프트웨어 기업체는 무엇을 
측정하여 야 하는가 하는것 이 다. 다음과 같은 5개 의 본질적이 며 근본적 인 척 도가 있 다. 

1. 크기 (코드 행수의 크기, 더 좋기는 9.2.1 에서 언급한것과 갈은 보다 의미 있는 척도 
에서의 크기로) 

2. 가격(딸라로) 

3. 기간(달수로) 

4. 효과(한사람당 한달동안의 작업 량으로) 
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5. 품질(발견된 오유의 개수로) 

매 척도들은 단계마다 측정되여야 한다. 이러한 근본적인 척도로부터 나온 자료에 
기 초하여 관리 자측은 설계 단계에서 의 높은 오유비률 또는 산업적기 준이하의 코드출력 과 
같은 쏘 프트웨 어기업체내에서 제기되는 문제들을 식별할수 있다. 일단 문제령역이 강조 
되면 이러한 문제점들을 정정하기 위한 전략이 고찰되여야 한다. 이러한 전략을 성공적 
으로 조종하기 위하여 보다 더 세 분화된 척도가 도입될수 있다. 실례 로 매 프로그람작성 
자들의 오유비률에 대 한 자료를 수집하거 나 사용자들의 만족성 정도를 측정하도록 하는것 
이다. 이처럼 5개의 기본적인 척도외에 보다 더 상세한 자료종합과 분석은 어떤 특정한 
목적 을 위하여 수행 되 여 야 한다. 

마지막으로 척도의 한 측면은 아직 더 론의할 여지가 있다. 대다수의 대중적인 척도 
의 타당성에 대하여 질문이 제기되였다. 즉 이러한 일부 문제들은 14.8.2 에서 론의를 진 
행한다. 우리 가 쏘프트웨 어개 발공정 을 측정할수 없는 한 그것 을 조종할수 없다는것 은 사 
실 이 라 할지 라도 무엇 이 측정 되 여 야 하는가에 관해 서 는 일 정 한 불일 치 가 존재 한다 
[Fenton and Pfleeger , 1997]. 

이 제 리 론적 인 도구들로부터 를퓨터 지원쏘프트웨 어공학 ( CASE ) 도구로 돌아 가 보자. 

5. 4. 콤퓨터지 원쏘프트웨어공학 ( CASE ) 

쏘프트웨어제품의 개발기간에는 서로 다른 여러가지 조작들이 수행되여 야 한다. 
전형적인 활동은 자원요구사항들의 평가，명세서의 작성, 통합시험의 수행，사용자지 
도서의 작성을 포함하게 된다. 그러나 유감스럽게도 이런 활동과 쏘프트웨어개발공정 
에서 의 그밖의 것 들은 인간의 개 입 이 없이는 콤퓨터 에 서 완전히 자동화되 거나 실행될 
수 없 다. 

그러 나 콤퓨터 가 매 단계 를 방조할수는 없 다. 이 절의 제 목인 CASE 는 콤퓨터 지원 
(또는 콤퓨터방조)쏘프트웨 어공학을 의 미한다. 콤퓨터는 계 획과 계 약，명세서, 설계，원천 
코드와 관리정보와 갈은 모든 종류의 인공적인 제품의 생성과 구성을 비롯하여 쏘프트웨 
어개 발과 관련된 많은 어 려 운 작업 의 수행 을 도울수 있 다. 문서 작성 은 쏘프트웨 어개 발과 
유지정비에서 필수적이지만 쏘프트웨어개발에 종사하는 대다수의 사람들은 문서를 새로 
작성하거 나 갱 신하는것 을 좋아 하지 않는다. 콤퓨터 들에 대 한 유지 정 비 선도는 쉽 게 변경 
될수 있기때문에 특히 쓸모가 있다. 

그러 나 CASE 는 문서 작성을 지 원하는데 국한되지 않는다. 특히 를퓨터는 쏘프트웨 
어공학자들로 하여 금 쏘프트웨 어개 발의 복잡성 에 대 처하도록 세 부적 인것 들을 관리하는 
데 도움을 줄수 있다. 그것 은 쏘프트웨 어공학을 위한 콤퓨터 지원의 모든 측면을 포함 
한다. 동시 에 CASE 는 콤퓨터 자동프로그람공학이 아니 라 콤퓨터 지원프로그람공학을 의 
미한다는것 을 기 억하는것 이 중요하다. 즉 콤퓨터 는 아직 쏘프트웨어 의 개 발이 나 유지 
정비와 관련하여 사람을 대신할수 없다는것이다. 앞으로도 콤퓨터는 기껏해야 쏘프트 
웨 어전문가들의 도구로 될 것 이 다. 
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5.5. 콤퓨터지원쏘프트웨어공학 ( CASE ) 의 분류 

CASE 의 가장 간단한 형식은 쏘프트웨어도구(切때 즉 쏘프트웨어생산의 한 측면만 
지원하는 제품이다. CASE 도구는 현재 생명주기의 모든 단계에서 리용된다. 실례로 다양 
한 여 러 가지 도구들이 나오고 있는데 대 부분의 도구들은 흐름선도와 같은 쏘프트웨어 제 
품의 도형 적 표현 들을 구성 하는데 도움을 주는 개 인 용콤퓨터 에 서 리 용된 다. 개 발공정 의 
보다 초기 단계 (즉 요구사항확정 과 명 세작성 그리 고 설 계 단계 )에 서 개 발자들을 방조하는 
CASE 도구들은 흔히 상위 CASE ( m 패 erCAffi ) 또는 앞단(/切방-에均도구라고 부르며 실현단계 
와 통합단계，유지 정 비 단계 를 지 원 하는 CASE 도구들은 하위 CASE ( fowerCAS £) 또는 뒤 단 
( tecit - emO 도구라고 부론다. 그림 5-8 의 1) 는 요구사항확정단계의 부분들을 지원하는 
CA 犯도구를 보여 주고 있다. 


요구사항확정 단계 


요구사항확정 단계 


요구사항확정 단계 

명세 작성 단계 


명세 작성 단계 


명세 작성 단계 

설 계 단계 


설계단계 


설계단계 

실현단계 


실현단계 


실현단계 

통합 단계 


통합 단계 


통합단계 

유지정비단계 


유지 정 비 단계 


유지 정 비 단계 


T ) 도구 니 작업대 c ) 환경 

그림 5-8. 도구，작업대，환경 

CASE 도구에 서 중요한 도구의 하나는 제 품에서 정의 된 모든 자료들의 콤퓨터화된 목 
륵인 자료사전 (dato dictionary ) 0 ] 큰 제 품들은 수만개 (수십 만개 는 아니 다.) 자료항목을 
포함하게 되며 콤퓨터는 변수의 이름과 행，그것이 정의되여 있는 위치 그리고 처리절차 
의 이 름과 파라메터，파라메터 의 형 과 같은 정 보들을 보관하는데 서 리상적 이 다. 매 자료 
사전입력점에 대하여 가장 중요한 부분은 항목들을 서술하는것이다. 실례로 새로 출생한 
갓난 애기의 몸무게를 입력으로 하고 한번에 먹여야 할 약의 량을 계산하는 처리절차라든가 
또는 비행기도착시간을 가장 뺘른 시간순서로 정돈하여 놓은 목록과 갈은 항목들을 서술하 
고 있다. 

자료사전의 능력 은 일 관성 검 사기 ( cons/sfewcy cfte (次 er ) 와 결 합되 여 강화될 수 있 다. 즉 
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명세서에 있는 매 자료항목이 설계단계에 반영되여 있고 반대로 설계단계에 있는 매 항 
목이 명세서에서 정의되였는가를 검사할수 있는 도구와 결합됨으로써 강화될수 있다. 자 
료사전의 또 다른 리 용은 보고서 생 성 프로그람 ( re / wr / g 라 jerator ) 파 화면 생 성 프로그람 
generator ) 에 대 한 자료를 제 공하는것 이 다. 보고서 생 성프로그람은 보고서 를 만드는데 필 요 
한 코드를 생 성하는데 리 용된 다. 화면생 성프로그람은 자료를 현시하는 화면을 구성 하기 
위한 코드를 작성하는데 서 쏘프트웨 어개 발자들을 지 원한다. 련쇄 된 책 방들의 매 가지 에 
서 주당 판매 를 입 력 하기 위한 하나의 화면 을 설 계 한다고 하자. 가지 의 수는 1,000-4,500 
까지 또는 8, 000-8,999 까지의 범위 에 있는 4자리옹근수이 며 화면에서 꼭대 기 에 있는 세 개 
의 행 에 입 력 된다. 이 정 보는 화면생 성프로그람에 보내 여 진다. 화면생성프로그람은 그다 
음 자동적 으로 꼭대 기 부터 세 개 행 에 문자렬 BRANCH NUMBER ---- 을 현시 하고 밑 줄을 
그은 첫 문자들에 유표를 표시하도록 하는 코드를 생성한다. 사용자가 매 수자를 입력하 
는데 따라 그것이 현시되고 유표는 다음 밑줄 그은 위치로 이동한다. 화면생성프로그람 
은 사용자가 수자만을 입 력했는가 결과적 인 4자리 옹근수가 특정한 범위 에 있는가를 검 사 
하고 코드를 생 성한다. 만일 자료가 타당치 못하게 입 력되거 나 사용자가 ?건을 누르면 
도움말정보가 현시된다. 

이러한 프로그람의 리용은 재빨리 구축되는 신속원형에 귀착될수 있다. 더우기 자료 
사전과 일 관성검 사프로그람, 보고서생 성프로그람과 화면생 성프로그람을 모두 결 합한 도 
형 적 인 표현 도구는 신속원 형 작성 을 지 원 하는 명 세 작성 과 설 계 작업 대 ( workbench ) 를 구성 한 
다. 이 모든 특성 을 병 합한 작업 대 의 실 례 자로는 PowerBuilder , Software through Pictures 과 
System Architect 를 들수 있다. 

CASE 작업 대 는 이 리하여 하나 또는 두가지 활동을 함께 지 원 하는 도구들의 집 합으로 
되는데 여기서 활동은 련관된 과제들의 집합으로 된다. 실례로 코드작성은 편집，를파일， 
련결，시험，오유검사를 포함하고 있다. 활동은 생명주기모형에서의 단계와 같은것이 아 
니다. 사실상 어떤 활동에서의 과제들은 지어 단계들의 경계를 교차할수도 있다. 실례로 
프로젝 트관리작업 대 는 프로젝 트의 매 단계 에 리용되 며 코드작성작업 대 는 실현과 통합， 
유지단계 는 물론 신속원형작성 에 리용될 수 있다. 그림 5-8 의 니은 상위 CASE 도구들에 
대 한 작업 대 를 보여 주고 있 다. 이 작업 대 는 명 세작성 과 설 계 단계 의 부분들을 위한 도구 
는 물론 그림 5-8 의 기의 요구사항확정단계 의 도구를 포함한다. 

CASE 기 술은 도구로 부터 작업 대 로 계 속 발전하고 있기때 문에 다음사항은 CASE 환경 
이 다. 하나 또는 두개의 활동을 지원하는 작업대와는 달리 환경은 완전한 生 
프트웨어개 발공정 또는 적 어도 쏘프트웨 어개 발공정의 큰부분을 지 원한다 [ Fuggetta ，1993]. 
그림 5-8 의 이은 생명주기의 모든 단계의 모든 측면을 지 원하는 환경을 보여 주고 있다. 
환경들에 대 해서는 제14장에서 보다 더 상세 히 론의한다. 

CASE 의 분류(즉 도구，작업 대 그리 고 환경)를 설정하였으므로 다음으로 CASE 의 범 


一 특정한 CASE 도구를 이 책 에서 인용한것은 저 자나 출판업체들에 의 한 그 CASE 도구 
의 보증에 대한 어떤 형식을 암시하고 있다. 이 책에서 언급한 매 CASE 도구는 실례로 되는 
CASE 도구들에서 전형적인 실례이기때문에 포함시켜 주었다. 
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위에 대하여 고찰한다. 

5.6. 콤퓨터지원쏘프트웨어공학 ( CASE ) 의 범위 

이 미 언급한바와 같이 언제 나 리용할수 있는 정 확하고 현대 적 인 문서 는 CASE 기 술을 
리용하는데서 나서는 1차적 인 요구로 되 고 있다. 실례 로 명세서 가 수동적 으로 작성 된다 
고 하자. 개발림성원들은 특정한 명세서가 현재의 판본인가 낡은 판본인가를 말할 방도 
가 없 다. 만일 그 문서 상에 서 손으로 씨 서 변경시 킨것 이 현재 의 문서 인지 또는 후에 제 
기된것 인지 알 방도가 없다. 다른 한편 만일 제 품에 대 한 명세서 들이 CASE 도구를 리용 
하여 만들어 지 면 그때 는 CASE 도구를 리용하여 접 근할수 있는 직 결식판본인 명세 서 에 
대 한 하나의 복제본만이 존재한다. 그때 만일 명세서 가 변화되 면 개발림성 원들은 쉽게 문 
서에 접근할수 있으며 그것들이 현재의 판본으로 보인다고 믿는다. 이밖에 일관성검사기 
는 명세서 에 대 응하는 변경 을 진행하지 않고 임의의 설계 변경들을 기 발로 표시할것 이 다. 

프로그람작성 자는 또한 직 결식문서를 요구한다. 실례 로 직결식방조정 보는 조작체 계， 
편집기, 프로그람작성언어 에 대하여 제공되여 야 한다. 이 밖에 프로그람작성 자는 편집지도 
서 , 프로그람작성 지도서 와 같은 많은 종류의 지 도서 들을 참고하여 야 한다. 가능한 모든 
곳에서 이러한 지도서들을 직결로 리용할수 있게 하는것이 아주 바람직하다. 모든것을 
가까이에 놓고 있는 편리성과는 달리 보통 적합한 지도서를 찾아 내고 필요한 항목을 찾 
아 보는것보다는 콤퓨터 에 질문하는것 이 더 빠르다. 이 밖에 보통 회사안에서 지도서 에 
대 한 모든 하드복사를 찾아 내 고 필 요한 폐 지 들을 변경하려 고 시 도하기 보다는 하나의 직 
결식 지도서 를 갱 신하는것 이 훨씬 더 쉽다. 결과 직 결 식문서 는 갈은 자료에 대 한 하드복 
사보다 더 정 확한것 같다. 이것 이 직결식문서 를 프로그람작성 자에 게 제 공해 주게 되는 
또 하나의 리 유로 된다. 이 와 같은 직 결식 문서 의 실례 는 UNIX 지 도서 이 다 [ Sobell ，1995]. 

CASE 는 또한 림성 원들사이 의 통신을 방조할수 있 다. 전자우편은 콤퓨터 나 확스와 
같은 보통 사무처 리를 훨씬 고속으로 해주고 있다. 전자우편은 우점 이 많다. 쏘프트웨어 
제 품의 견지 에 서 보면 특정한 프로젝 트와 관련 한 모든 전자우편에 대 한 복사들이 특정한 
우편통에 저장되면 거기에는 프로젝트를 개발하는 기간에 만들어 지게 되는 결정들을 저 
장한 기록이 있게 된다. 이것은 후에 일어 날수 있는 충돌을 해소하는데 리용된다. 많은 
CASE 환경들과 일부 CASE 작업대는 지금 전자우편체계를 병합하고 있다. 기타 회사들에 
서는 전자우편체 계 를 Netscape 와 같은 WWW 열 람기를 통하여 실현하고 있 다. 이 와 맞먹 
는 도구들가운데 는 표처 리프로그람과 문서처 리프로그람이 있다. 용어코드작성 도구 
{coding too /) 는 본문편집 기 , 오유수정 프로그람 그리 고 프로그람작성 자의 과제 를 단순 
하게 하고 많은 프로그람작성 자의 능률을 높이 기 위하여 설계 된 기 묘한 인쇄프로그 
람 (pretty printer)^- 같은 CASE 도구들과 련관된다. 이러한 도구들을 론의 하기 전에 다 
음의 세가지 정의가 필요하다. 소규모프로그람작성 治-功 은 단일 모둘 

코드준위 에서의 쏘프트웨 어 개 발로 간주되 며 반면에 대 규모프로그람작성 ( pragraww & g -/«- 
the - large ) 은 모둘준위 의 쏘프트웨 어 개 발이 다 [DeRemer and Kron , 1976]. 후자는 구성 방식 설 
계 와 통합파 같은 측면 을 포함하게 된 다. 다수프로그람작성 ( pragrawm / wg - 初-功은 
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대 규모프로그람작성 과 소규모프로그람작성 의 두 측면들을 결 합하고 있 다. 

구조편집 기 ( sfrwc/wre editor ) 는 실현언어 를《 리 해》하는 본문편집 기 이 다. 즉 구조편집 
기 는 무익한 콤파일 에 서 시 간이 랑비되 기 때 문에 실현 단계 를 앞당기 기 위하여 프로그람작 
성자가 건반으로 입력하자마자 문법적인 오유를 찾아 낼수 있도록 한다. 구조편집기는 
매우 다양한 언어들과 조작체계, 하드웨어내에 포함되여 있다. 구조편집기는 프로그람작 
성언어 에 대 한 지 식을 가지 고 있기때 문에 코드의 좋은 시각적출현을 늘 담보할수 있도륵 
인쇄프로그람(또는 형 식 화프로그람)을 본문편집 기 에 쉽 게 병 합할수 있다. 실례 로 C ++ 를 
위한 기 묘한 인쇄프로그람은 그에 대 응하는 } 가 대 응하는 {만큼 같이 들여 쓰기하도록 담 
보해 준다. 형식화프로그람을 병합한 구조편집기의 초기의 실례는 마킨토쉬，파스칼편집 
기 이다 [ Apple , 1984]. 예 약된 단어들 두드러 지게 나타나도록 자동적으로 강조체로 되며 
들여 쓰기 는 읽 기 쉽 게 하기 위하여 주의 깊게 설계 되 였 다. 사실상 많은 마킨토쉬본문편집 
기들은 전체적으로 또는 부분적으로 구조화되여 있다. 

다음으로 어 떤 방법 이 존재하지 않거 나 그것 이 어 떤 방식 으로 잘못 규정되 였 다는것 
을 련결 과정 에 발견 하기 위하여 코드내 에 서 그 방법 을 호출하는 문제 를 생 각해 보자. 이 
때 구조편집기가 직결식대면부검 사 interface checking ) 를 지원하도록 하는것 이 필요 
하다. 즉 구조편집 기 가 프로그람작성 자에 의해서 선언된 매 변수의 이 름과 관련한 정 보 
를 가질 때와 마찬가지로 제품안에서 정의된 매 방법들의 이름들도 알아야 한다. 실례로 
프로그람작성 자가 다음과 같은 호출 

average = dataArray . compute Average(numberO fV alues ); 

을 입 력 하였지만 방법 computeAverage 가 아직 정의되지 않았다면 그때 편집 기는 즉시 에 
다음의 통보문 


Method computeAverage not known 


으로 응답한다. 

이 점에서 프로그람작성자는 방법의 이름을 정정하든가 또는 computeAverage 라는 새 
로운 방법 을 정 의하든가 하는 두가지 선택 을 하게 된다. 만일 두번째 를 선택 한다면 프로 
그람작성 자는 또한 새 로운 방법 에 대 한 인수들을 목록에 기 입하여 야 한다. 직 결 식 대 면부 
검사를 하는 주요한 원인이 바로 방법의 이름이 아니라 전체의 대면부정보를 정확히 검 
열 할수 있게 하는것 이 기때 문에 새 로운 방법 을 정의할 때 인수의 형 을 주어 야 한다. 일 반 
적인 오유는 방법 q 가 5개의 인수를 가지는데 방법 p 가 이를테면 4개의 인수를 넘겨 주 
는 방법 q 를 호출하는것 이 다. 호출이 정 확히 4개 의 인수를 리용하고 있지 만 두개 의 인수 
가 바뀌여 져 있을 때는 오유를 발견하기가 더욱 어렵다. 실례로 방법 q 의 선언이 

void q(float floatYar , int intYar , s 仕 ing si , string s 2) 

이고 반면에 호출은 


q ( intYar , floatVar , si , s 2); 

이다. 호출명령문에서 첫 두개의 인수는 바뀌여 져 있다. Java 콤파일러와 련결프로그람은 



이 오유를 발견은 하지만 다만 그것들이 그후에 호출될 때에만 그렇게 될수 있다. 대비 
적으로 직결식대면부검사기는 즉시 이러한 오유와 이와 류사한 오유들을 발견한다. 이밖 
에 편집 기 가 방조능력 을 가진다면 프로그람작성 자는 q 에 대 한 호출을 코드작성 하기전에 
방법 다의 정 확한 인수에 대 한 직 결 정 보를 요구할수 있다. 지 금은 더 좋게 되 여 있다. 편 
집기는 호출에 대한 형타를 생성하여 매 인수에 대한 형을 보여 주고 있다. 프로그람작 
성 자는 단지 정 확한 형 에 따르는 실제적 인 인수를 매 형 식적 인 인수로 교체하여 야 한다. 

직 결 식 대 면부검사의 주요한 우점 은 인수의 개 수가 맞지 않게 방법 을 호출한다거 나 
또는 형이 맞지 않게 방법을 호출함으로써 일어 나는 발견하기 힘든 오유들을 즉시에 표 
식해 주고 중지시킨다는것이다. 직결식대면부정보는 특히 쏘프트웨어가 림에 의해서 개 
발될 때(다수프로그람작성) 품질이 좋은 쏘프트웨어를 효률적으로 생산하는데서 중요한 
역할을 한다. 모든 모둘들과 관련한 직결식대면부정보는 전기간 모든 프로그람작성림 
성 원들에 게 리용될 수 있 다는것 이 본질 적 인 문제 이 다. 더우기 한명 의 프로그람작성 자가 
한개 인수의 형 을 int 에서 float 로 변화시키거 나 또는 추가적 인 인수를 보충함으로써 방 
법 vaporCheck 의 대면부를 변경시키면 vaporCheck 를 호출하는 모든 구성부분들은 련관된 
호출명 령 문들이 사건의 새 로운 상태 를 반영 하기 위하여 바뀌 여 질 때 까지 자동적 으로 무 
시되여야 한다. 

지 어 직 결대 면부검사기 를 병 합한 문법 지향편집 기 를 가지 고서 도 프로그람작성 자는 여 
전히 편집기로부터 탈퇴하여 콤파일러와 련결프로그람을 호출해야 한다. 명백히 콤파일오 
유는 없지만 콤파일러는 여전히 코드생성을 하도록 호출되여야 한다. 그다음 련결프로그 
람이 호출되 여 야 한다. 또한 프로그람작성 자는 직 결 대 면부검 사기 가 존재하는것 으로 하여 
모든 외 부적 인 참고가 만족되지 만 련결프로그람은 아직 도 제품을 련결 하기 위하여 필요된 
다고 믿 을수 있 다. 이 에 대 한 해 결책 은 편집 기 내 에서 조작체 계 앞단처 리 ( o 夕 
front - end ) 를 병합하는것이다. 즉 프로그람작성자는 조작체계에 편집기로부터 오는 명령를 
을 줄수 있 어 야 한다. 편집 기 가 를파일 러 와 련결 프로그람，적 재프로그람과 그리 고 모둘이 
실행 되 도록 하여 야 할 필요가 있는 기 타 다른 체 계쏘프트웨어 를 호출하도록 하기 위하여 
프로그람작성 자는 GO 또는 RUN 이 라는 간단한 지 령 을 입 력 하거 나 마우스로 적 당한 그림 
기 호나 차림 표를 선택할수 있다. UNIX 에서 는 이 것을 wafe 지 령 (5.9) 을 리용하거 나 쉴스크 
립트(始 e//scr 中/)를 호출하여 실현시 킬수 있다 [ Sobell , 1995]. 이 러한 앞단처 리는 다른 조작 
체 계들에서도 역시 실현하고 있다. 

가장 실망케 하는 계 산경 험 은 제 품으로 하여 금 Is 동안에 실 행하게 하고 그다음에 는 
Overflow at 506 

과 같은 통보문을 인쇄하면서 다급히 끝내 는것 이 다. 프로 그람작성 자는 아쌤 블리 나 기 계 
코드와 같은 낮은 준위의 언어가 아니라 Java 나 C ++ 와 같令 고급언어를 가지고 프로 그 
람작성 을 한다. 그러 나 오유수정 기 능지원 이 Overflow at 506 의 변종들일 때 프로 그람작성 
자는 기 계 코드핵 담프, 아쎔 블리 어목록작성，련결 프로 그람목록작성 , 기 타 여 러 가지 낮은 
준위언어문서들을 시험해 야 하며 그로 말미암아 고급언어 프로 그람작성의 총체적 인 우월 
성 이 상실되게 된다. 주어 진 유일한 정 보가 잘 알려 지지 않은 UNIX 통보문 
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이거나 마찬가지로 유익하지 못한 


Core dumped 


Segmentation fault 

인 경우에 이와 류사한 정황이 발생한다. 여 기서 다시 사용자는 낮은 준위의 정 보를 시 
험하여 야 한다. 

실패 와 관련하여 그림 5-9 에 서 보여 준 통보문은 앞에 서 의 간결한 오유통보문에 비 
해 서 큰 개 선으로 된다. 프로그람작성 자는 즉시 에 0으로 나누기하여 방법 이 실패하였 다 
는것 을 알수 있다. 조작체 계 에 대 하여 편집 방식 을 입 력 하고 오유가 발견된 행 즉 례하면 
6행 을 그 앞뒤 의 4~5개행 과 함께 자동적 으로 현시하도록 하는것 이 더 욱 쓸모 있 다. 그러 
면 프로그람작성 자는 실패한것 이 무엇 이 고 어 떤 변경 을 진행해 야 하는가를 알수 있다. 
또 다른 류형 의 원천준위 의 오유검 사는 추적 이다. CASE 도구들이 출현하기전에 는 프로그 
람작성 자들이 코드에 수동적 으로 적 당한 입 력지 령을 삽입하여 야 하였다. 즉 실행할 때 
행번호와 관련된 변수들의 값을 가리키도록 하였다. 지금은 이것을 자동적으로 측정결과 
를 생성해 내도록 하는 원천준위오유수정프로그람 CsoMrce -/ eve /- 쇼 에 지령을 주어 

실 현 하고 있 다. 더 좋은 대 화식 원 천준위 오유수정 프로그람(切 /eracftVe 
이 있 다. 변수 escapeVelocity 의 값이 정 확치 않고 방법 computeTrajectory 에 오유가 있는 
것 같다고 가정 하자. 대 화식원천준위 오유수정프로그람을 리용하여 프로그람작성 자는 코 
드상에 정지점 을 설정할수 있다. 정지점 에 이르게 되 면 실행 이 정지되 고 오유수정방식으 
로 들어 간다. 프로그람작성 자는 이 제 오유수정프로그람에 변수 escapeVelocity 와 방법 
computeTrajectory 를 추적하라고 요구한다. 


OVERFLOW ERROR 

Class: cyclotronEnergy 

Method: performCompulation 

Line 6: newValoe = (oldVolue + tempVofue)/tempValue; 

oldValue = 3.9583 tempValue — 0.000 


그림 5-9. 원천준위 오유수정 프로그람의 출력 

즉 escapeVelocity 의 값이 련속적으로 리용되기도 하고 변화되기도 할 때마다 매번 실 
행 이 다시 중지된다. 그때 프로그람작성 자는 또 오유수정지 령 을 입 력하게 된다. 실례 로 
특정한 변수의 값이 현시 되 도록 요구하게 한다. 프로그람작성 자는 오유수정방식 으로 계 
속 실행하는가 또는 보통실행방식 으로 되돌아 가는가를 번갈아 선택할수 있다. 프로그람 
작성 자는 방법 computeTrajectory 가 입 력 되거 나 중지될 때 마다 오유수정 프로그람과 대 화 
할수 있 다. 이 런 대 화식원천준위오유수정프로그람은 제 품이 실패할 때 프로그람작성 자에 
게 모든 형 태의 도움을 주게 된다. UNIX 오유수정프로그람 dbx 는 이 와 같은 CASE 도구의 
실례로 된다. 
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이미 강조한바와 같이 모든 종류의 문서가 직결로 리용될수 있다는것이 중요하다. 프 
로그람작성자의 경우에 필요한 모든 문서는 편집기 안에서부터 접근가능하여야 한다. 방 
금 서술한것들 즉 직결식대면부검사능력, 조작체계 앞단처 리，원천준위오유수정 프로그람， 
직 결식 문서 작성 들을 가지 고 있는 구조편집 기 는 충분하고도 효과적 인 작업 대 를 구성 한다. 

이 런 종류의 작업대는 결코 새로운것 이 아니 다. 앞에서 렬거한 모든 특성은 1980년 
이전의 FLOW 쏘프트웨 어 개 발작업대 에서 지 원되 였다 [Dooley and Schach ，1985]. 그러므로 
최소이지만 본질적인 프로그람작성작업대로서 제시될 수 있게 되기전에는 여러해동안의 
연구를 필요로 하지 않는다. 아주 상반되 게 필요한 기 술은 20년 이상 걸 렸고 싼 ( Sun ) 쏘프 
트웨 어 회 사와 같이 작업 대 를 리용할 대 신에 여 전히 《 낡은 방식》으로 코드작성 을 실현 
하는 프로그람작성자들도 있다는것은 놀라운 일이다. 

특히 림 이 쏘프트웨어 를 개 발할 때 필수적 인 도구는 판본조종도구이 다. 

5. 7. 쏘프트웨어판본 

제품이 유지정비될 때마다 적어도 제품에 대하여 두개의 판본 즉 낡은 판본과 새로 
운 판본이 있게 된다. 제품은 모둘들로 구성되기때문에 역시 변화가 진행된 매 구성모둘 
에 대하여 두개이상의 판본이 있게 된다. 

판본조종은 처음에는 유지정 비 단계의 범위 안에서 서술되여 있고 그다음에는 개 발공 
정의 보다 앞단계들을 포함하도록 확장되였다. 

5. 7. 1 . 개정판 

어떤 제품이 여러 곳에 설치되였다고 하자. 만일 모둘에서 오유가 발견되면 그 모둘 
은 보수되여야 한다. 적당히 변경을 진행한 다음에는 그 모둘에 대하여 두개의 관본이 
존재하게 된다. 즉 교체하려고 하는 낡은 판본과 새판본이 있을것 이다. 이 새로운 판본을 
개정판이라고 한다. 여러개의 판본의 존재는 명백히 낡은 판본은 버리고 새로운것만을 
남겨 두도록 함으로써 쉽게 해결되게 된다. 그러나 그것은 아주 어리석令 짓이다. 이전 
판본의 모둘이 개정 판 n 이 고 새 로운 판본은 개정 판 n +1 이 라고 하자. 개정관 n +1 이 쏘프 
트웨어품질담보 ( SQA ) 그롭에 의해서 고립적으로 또는 제품의 나머지부분과 련결시켜 철 
저히 시험되 였더 라도 사용자가 새 로운 판본의 제품을 실제 적 인 자료를 가지 고 실행할 때 
는 손해 가 막심한 결과가 초래될수도 있다. 개정 판 n 은 다음의 두번째 리유로 하여 유지 
정 비하여 야 한다. 제 품은 여 러 곳에 분포되 였고 그것들은 모두 개정 판 n +1 을 설 치하지 
않았을수도 있다. 만일 여전히 개정 판 n 을 리용하고 있는 곳에서 오유보고서를 보내오면 
그때 는 이 새 로운 오유를 분석 하기 위하여 사용자들이 설 치한것 과 같은 방법 으로 정 확히 
제품을 구성배치하고 그 모둘의 개정판 n 을 병합하여야 한다. 그러므로 모든 모둘의 매 
개 정 판의 복제본을 보관해 두는것 이 필요하다. 

1.3 에 서 서 술한바와 같이 해 당한 제 품의 기 능을 확장하기 위하여 완전유지 정 비 가 
진행된다. 일부 경우에는 새로운 모둘들이 작성된다. 즉 기타 다른 경우에 현존 모둘들 
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은 이런 추가적인 기능을 병합하도록 변경된다. 이런 새로운 판본은 또한 현재의 모둘 
에 대한 개정판으로 된다. 적응유지정비가 진행될 때 모둘은 변경된다. 즉 제품이 동작 
하는 주위환경에서의 변화에 대응하여 제품에 대한 변경이 이루어 진다. 문제는 바로 
유지정 비단계 에서 제 기되는것 이 아니 라 실현단계 와 그이전단계 들에서 발생 하기때 문에 
정확히 유지정비가 진행되면 그이전의 모든 판본들은 유지정비되는것으로 된다. 결국 
일단 모둘이 코드작성되면 오유들이 발견되여 정정되는 결과에 계속 변경이 이루어 지 
게 된다. 결과 매 모둘에 대하여 수많은 판본들이 존재 하게 되며 개 발림의 매 성원들이 
어느 판본이 어떤 주어 진 모둘에 대한 현재의 관본이라는것을 안다는것을 담보하도록 
어떤 종류의 조종을 진행하는것이 사활적인 문제이다. 이 문제에 대한 해결방안이 제기 
될수 있기전에 그이상의 복잡성이 고려되여야 한다. 


5. 7. 2. 변령판 


다음의 실례를 고찰하자. 대부분의 콤퓨터는 한가지이상의 인쇄기를 지원하고 있다. 
실례로 개 인용를퓨터 는 잉크분사식 인쇄기 와 레 이 자인쇄기를 지 원할수 있다. 그러 므로 조 
작체계는 인쇄기구동프로그람에 대 한 두개의 변종을 포함해 야 한다. 즉 매 인쇄기에 대 
하여 하나의 인쇄기구동프로그람을 포함해야 한다. 개정판과는 달리 매개가 그 처리절차 
프로그람으로 명백히 교체하도록 하는 변형판들이 동시에 존재할수 있도록 설계되여야 
한다. 변형판들이 필요하게 되는 또 다른 하나의 상황은 제품이 서로 다른 조작체계나 
하드웨어에 대한 변종들에 대하여 처리를 진행하게 될 때이다. 많은 모둘들에 대한 서로 
다른 변형판들은 매 조작체계와 하드웨어의 결합을 고려하여 작성되여야 할수도 있다. 

변형판들을 구조도식 으로 그림 5-10 에서 보여 주었는데 여 기서 는 개 정 판과 변형판들 
을 모두 보여 주고 있다. 


1 ) 



L) 

그림 5-10. 여 러 판본의 모형에 대한 도식적 인 표현 
T ) 개정판， L ) 변형판 
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문제가 더 복잡해 지면 일반적으로 매 변종판에 대하여 여러개의 개정판들이 있게 
된다. 쏘 프트웨 어기업체가 여러개의 판본으로 인한 곤경에 빠져 들어 가는것을 극복하기 
위하여 CASE 도구가 필 요하게 된 다. 

5. 8. 구성조종 

매개 모둘에 대한 코드는 세가지 형식으로 존재하게 된다. 그 하나가 원천코드인데 
지 금은 보통 C ++, Java , Ada 와 같은 고급언어 로 작성 되 고 있 다. 그다음은 원천코드를 콤 
파일 하여 생 성 한 목적 코드이 다. 마지 막으로 매 개 모둘에 대 한 목적 코드가 수행 적 재 가능 
한 프로그람을 생성하기 위하여 실행시간루린과 결합된다. 이것을 그림 5-11 에 보여 주 
었 다. 



그림 5-11. 수행적재가능한 프로그람의 구성요소 

프로그람작성 자는 매 개 모둘의 여 러 가지 서 로 다른 판본을 리용할수 있다. 완성 된 
제 품의 주어 진 판본이 만들어 지 게 되 는 그런 매 개 모둘의 특정한 판본을 그 제 품에 해 
당한 판본의 구성 배 치 라고 한다. 프로그람작성 자에 게 어 떤 모둘이 특정한 어 떤 시 험자료 
모임 에 대 하여 실패하였 다는것 을 서 술한 SQA 그룹의 시 험 보고서 가 제 공되 였 다고 하자. 
첫번째로 하여 야 할 일들중의 하나는 실패를 다시 생성해 보는것 이 다. 그러 나 어느 변종 
의 개정판이 파괴된 제품의 판본으로 되 겠는가를 프로그람작성 자가 어떻게 결정할수 있 
는가? 만일 구성조종도구(아래 에 서 론의 된다.)를 리용하지 않는다면 오유의 원 인을 정 확 
히 지 적 하기 위한 유일한 방도는 8진수나 16진수형 식 으로 되 여 있는 수행적 재 가능한 프 
로그람을 조사하여 그것 을 8진수나 16진수로 된 목적코드와 비 교해 보는것 이 다. 특히 여 
러가지 판본의 원천코드는 콤파일되 여 수행적재 가능한 프로그람으로 전환된 목적코드와 
비교해야 한다. 비록 이렇게 할수 있다고 하더라도 매 제품이 여러개의 판본을 가진 수 
십 (수백 은 아니 다.)개 의 모둘로 이 루어 졌 다면 이 과정 에 는 오랜 시 간이 걸릴수 있 다. 이 
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로부터 여러개의 판본을 취급할 때 두가지 문제가 해결되여야 한다. 첫째는 매개 모둘에 
대한 정확한 관본이 콤파일되여 제품에 련결되도록 판본들사이를 구별해 줄수 있어야 한 
다는것 이 다. 둘째 문제는 우와 반대 이 다. 즉 수행적재가능한 프로그람이 주어 지면 그것 
을 구성하는 매 요소들의 어느 판본이 그것으로 전환되였는가를 결정해야 한다. 

이 문제를 해결하는데 필요한 첫번째 항목은 판본조종도구이다. 많은 조작체계들 
특히 대 형콤퓨터 들에서는 판본조종기 능을 지 원하고 있다. 그러 나 대 부분의 체 계 들에서 
는 이 기능을 지원하지 않으며 이 경우에는 개별적인 관본조종도구가 필요하다. 판본 
조종에서 리용된 보편적 인 기술은 매 파일의 이름을 두 부분 즉 파일이름 그자체와 개 
정 판수로 구성하는것 이 다. 이 리하여 통보문의 접수를 승인한 모둘은 그림 5-12 의 자)에 
서처럼 acknowledgeMessage / 1, acknowledgeMessage /2 등과 같은 개정판을 가지게 될것이다. 
프로그람작성 자는 그때 주어 진 과제 를 위하여 어 느 개정 판이 필요한가를 정 확히 규정할 
수 있다. 



L) 


a 림 5-12. 여러가지 개정판과 변형판들 
一 I ) 모듈 acknowledgeMessage 의 네 개의 개정 판，니 변형 판 printerDriver ( laser ) 에 
대한 세개의 개정을 가지고 있는 모듈 printerDriver 의 두개의 변종 

여 러개의 변형판(다른 상황에서 같은 역 할을 수행하는 판본들을 약간 변화시 킨것)들 
에 대한 하나의 유용한 표기법은 기본적인 파일이름뒤에 괄호안에 넣.욘 변종이름을 놓는 
것 이 다 [ Babich , 1986]. 이 리 하여 두개 의 인쇄 기 구동프로그람에 printerDriver (加 cJet ) 와 
printerDriver ( laser ) 라는 이름을 주게 된 다. 

물론 printerDriver ( laser )/12, printerDriver ( laser )/13, printerDriver ( laser )/14 와 같이 매 변형 
판에 대하여 여러개의 개정판이 있게 될것이다. 이것을 그림 5-12 의 니에서 보여 주었다. 

판본조종도구는 여 러개의 판본을 관리할수 있도록 하는 첫 걸음으로 된다. 일단 판 
본조종도구가 설 치되면 제품의 여 러 가지 판본에 대 한 상세한 기록(또는 파생물)을 보존 
하여 야 한다. 파생물은 매 원천코드요소의 이 름을 포함하고 있 다. 이 와 함께 변형판과 개 
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정판 그리고 리용된 여러가지 콤파일러와 련결프로그람의 관본，제품을 개발한 사람의 
이름과 제품이 개발된 날자와 시간 등을 포함하고 있다. 

판본조종은 모둘과 제품전반에 대한 여러가지 판본을 관리하는데 큰 도움을 준다. 
그러 나 여 러 가지 변형 판은 유지 와 관련한 추가적 인 문제 가 제 기 되 는것 으로 하여 판본조 
종이 더욱 필요하게 된다. 

두 개 의 변 형 판 printerDriver(inkJet) 와 printerDriver(laser) 에 대 하 여 고 찰 해 보 자 . 
printerDriverGnkJet) 에서 오유가 발견되였고 오유는 두 변형 판의 공동적인 모둘의 어느 한 
부분에서 발생 하였다고 가정 하자. 그때는 printerDriver(inkJet) 만이 아니 라 printerDriver(laser) 
에 대 해서 도 보수해 야 할 필요가 있다. 일 반적 으로 하나의 모둘에 대 하여 v 개의 변형판 
이 있다면 v 개의 변형판이 모두 수정되여야 한다. 뿐만아니라 그것들은 다 같은 방법으 
로 수정 되 여 야 한다. 이 문제 에 대 한 한가지 해 결 방안은 printerDriver(inkJet) 라고 하는 
하나의 변형판을 보관하는것 이 다. 그다음 임의의 다른 변형판은 원래의 판본으로부터 
변형판으로 가서 만들어 져야할 변경들의 목록에 의하여 보관된다. 이와 같이 차이나는 
것 들에 대 한 목록을 델 타(쇼/ to ) 라고 부론다. 그러 므로 보관된것 은 한개 의 변형판과 v-1 
개 의 델 타들이 다. 변형 판 printerDriver(laser) 는 여付대 01 切때加 £ ；탸)를 호출하고 델 타를 적 용 
하여 회복된다. 바로 printerDriver(laser) 에 대하여 만들어 지는 변경은 적당한 델타를 변 
화시키 는것 으로써 실현된다. 그러 나 원래 의 변형판인 printerDriver(MJet) 에 대 한 변경 은 
자동적 으로 다른 모든 변형판들에 적 용되 게 된다. 

구성조종도구는 여러개의 변형판들을 자동적으로 관리할수 있다. 그러나 구성조종 
은 여러개의 변형판들을 초월하여 진행된다. 구성조종도구는 또한 다음 절에서 서술하 
는바와 같이 림 에 의하여 개 발되 고 유지정 비 되는 과정 에 제 기되 는 문제 들을 관리할수 
있 다. 


5. 8. 1. 제품유지정비단계에서의 구성조종 

한명이상의 프로그람작성자가 동시에 하나의 제품을 유지정비하고 있을 때에는 온갖 
종류의 난관이 제기될수 있다. 실례로 월요일 아침에 두명의 프로그람작성자들에게 각각 
서로 다른 오유보고서를 준다고 하자. 동시에 두 프로그람작성 자는 같은 모둘 mDual 에서 
의 서로 다른 부분에서 수정될 오유들을 나누어 가지게 된다. 매 프로그람작성자는 
mDual/16 이 라는 모둘의 현재 판본을 복사하고 오유에 대 하여 수정 을 시 작한다. 첫 사람 
은 첫 오유를 퇴 치 하고 변경 이 승인되 면 그 모둘을 mDual/17 이 라는 모둘로 교체한다. 그 
다음날에 두번째 프로그람작성 자는 두번째 오유를 뢰치 하고 변경 이 승인되 면 모둘 
mDual/18 을 설 치한다. 유감스럽게도 개정판 17 은 첫 프로그람작성 자에 의한 변경만을 포 
함하고 개정 판 18 은 다만 두번째 프로그람작성 자에 의한 변경 만을 포함한다. 이 리하여 
첫 프로그람작성 자에 의한 변경 은 모두 잃 어 지 게 된다. 

비록 매 프로그람작성자가 어떤 모둘의 개별적인 복사본을 만들도록 하는 착상이 두 
프로그람작성 자가 쏘프트웨어 의 같은 부분에 서 함께 일하는것 보다 훨씬 좋다고 할지 
라도 그것은 명백히 림에 의하여 유지정비를 진행하는데는 적당치 않다. 필요되는것은 
다만 한명 의 사용자가 한번 에 모둘을 변화시키 도록 하는 기 구가 필 요하다. 
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5. 8. 2. 기준선 


유지정비관리자는 제품에 있는 모든 모둘들에 대한 구성배치(판본의 모임)인 기준선 
을 설정해야 한다. 오유를 찾으러고 할 때 유지정비프로그람작성자는 필요한 모둘에 대 
한 복제본들을 개별적인 작업공간에 넣어 준다. 이 개별적인 작업공간에서 프로그람작성 
자는 임의의 방법으로 다른 프로그람작성자에게 영향을 주지 않는 임의의 모든것을 변화 
시킬수 있다. 왜냐하면 모든 변경들은 프로그람작성자의 개별적인 복제본에서 만들어 지 
기때문에 기준판본은 손대지 않은채로 남아 있게 된다. 

일단 모둘이 오유를 되치하기 위하여 변경되여야 한다는것이 결정되면 프로그람작성 
자는 교체하려는 모둘의 현재판본을 동결시키게 된다. 다른 모든 프로그람작성자들은 
동결시킨 판본을 변경시킬수 없다. 유지정비프로그람작성자가 변경을 진행하고 그 변 
경들이 시험된 다음 모둘의 새로운 판본이 설치되고 그로 인하여 기준선이 수정된다. 
동결된 이전의 판본은 이미 설명한바와 같이 앞으로 필요되기때문에 보존되여 야 하지만 
교체되지는 않는다. 일단 새로운 판본이 실현되면 그 어떤 다른 유지정비프로그람작성자 
가 새로운 판본을 동결시키고 거기에 변경을 진행한다. 결과적인 모둘은 차례로 다음의 
기준판본으로 되게 된다. 만일 두개 이상의 모둘이 동시에 변경되여야 한다면 류사한 처 
리절차가 진행된다. 

이러한 도식은 모둘 mDual 에서 제기되는 문제를 해소한다. 두 프로그람작성자는 
mDual /16 에 대 하여 개 별적 인 복사를 진행 하고 그 복제 본들을 수정 하여 야 할 개 개의 오유 
들을 분석하는데 리용한다. 처 음의 프로그람작성 자는 무엇 을 변경시 키 겠는가를 결정 하고 
mDual /16 을 동결시킨다. 그리고 첫 오유를 뢰치 하기 위 하여 거기에 변경을 진행 한다. 변 
경 이 시험된 다음에 결과적 인 개정 판 mDual /17 을 기준판본으로 설정한다. 한편 두번째 
프로그람작성 자는 mDual /16 에 대 한 개 별적 인 복제 본를 가지 고 실험 함으로써 두번째 오유 
를 찾아 낸다. 그러나 그것이 첫 프로그람작성자에 의해서 동결되였기때문에 이제는 
mDual /16 에 대하여 변경 이 진행되지 않는다. 일단 mDual /17 이 기준판본으로 되면 그것은 
mDual /17 에 변경을 진행하는 두번째 프로그람작성자에 의해서 동결된다. 결과적인 모둘 
은 mDual /18 즉 두 프로그람작성자가 협력 하여 변경 시킨 판본으로서 설치된다. 개정판 
mDual /16 과 mDual /17 은 앞으로 참고하기 위 하여 유지 정 비 되 지 만 절대 로 변경 될수 없 다. 

5. 8. 3. 제품개발에서의 구성조종 

모둘이 코드작성되는 동안 판본은 너무 빨리 변경되므로 구성조종에 도움을 주지 
못한다. 그러 나 일단 모둘에 대한 코드작성 이 완성되면 그것은 6.6 에서 서술한바와 같이 
즉시 프로그람작성자에 의하여 비형식적으로 시험되여야 한다. 이러한 비형식적인 시험 
을 진행하는 기 간에 모둘은 또다시 많은 판본들로 변경 되 게 된다. 프로그람작성 자가 
동의하면 그것은 규칙적 인 시험 을 진행 하기 위하여 SQA 그룹에 넘겨 진다. 모둘은 SQA 
그룹을 통과하자마자 제 품으로 통합될 준비 가 된 다. 그때 로부터 그것 은 유지정 비단계 에 
서와 갈은 구성조종처리절차에 복종되게 된다. 통합된 모둘에 대한 임의의 변경은 유지정 
비단계에서 변경 이 이루어 진 방법으로 제품전반에 대하여 영향을 줄수 있다. 따라서 구성 
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조종은 유지정 비 단계 에서 뿐아니 라 실현단계 와 통합단계 에서도 필요하게 된다. 더 우기 
매 개 모둘이 합리 적 으로 되 자마자 즉 그것 이 SQA 그룹을 통과한 다음에 구성조종에 복 
종되 지 않으면 관리 자측은 개 발공정 을 충분하게 감시할수 없 다. 구성조종이 정 확히 적 
용될 때 관리자는 매 모둘의 상태를 알아 차리고 프로젝트의 최종기 한이 다가오는것 같 
으면 신속하게 정 확한 행동을 취 함수 있다. UNIX 에서 주요한 세개의 판본조종도구로는 
sees (원천 코드조종체 계 ; source code control ■ s > w / em )[ Rochkind , 1995] 와 res (개 정 판조종체 계 ; 
revision control system )[ Yichy , 1985] 그 리 고 cvs ( 병 행 판 본 체 계 ; concurrent versions 
5 j 5 tem)[Loukides and Oram , 199 刀 이 있 다. PVCS 는 대 중적 인 구성 조종도구이 다. 마이 크로 
쏘프트의 SourceSafe 는 개 인용콤퓨터 를 위한 구성 조종도구이 다. 

5. 9. 구 축 도 구 

만일 쏘프트웨어기업체가 완전한 구성조종도구를 구입하려고 하지 않으면 그때는 적 
어도 구축도구가 판본조종도구 즉 제품의 특정한 판본을 구성하기 위하여 련결되는 매개 
목적코드모둘의 정확한 판본을 선택하는것을 도와 주는 도구와 결합하여 리용되여야 한 
다. 임의의 시간에 매개 모둘에 대한 여러개의 변형판과 개정판들이 제품서고에 있을것 
이 다. 어떤 판본조종도구는 사용자가 원천코드모둘의 여 러 가지 판본들을 식별해 내는것 
을 도와 줄것 이 다. 그러 나 일부 판본조종도구는 목적판본에 개정관번호를 붙이지 않기때 
문에 목적코드를 추적하기가 어렵 다. 

이에 대처하여 일부 기업체들은 매 모둘의 최신판본을 자동적으로 콤파일하여 모든 
목적코드가 항상 갱신되게 한다. 비록 이 기법을 리용해도 불필요한 콤파일이 많이 진행 
되 기 때 문에 콤퓨터 작업 시 간이 매 우 랑비 될 수 있 다. UNIX 도구 make 는 이 문제 를 해 결 할 
수 있 다 [ Feldman , 1987]. 매 수행 적 재 가능한 프로그람에 대 하여 프로그람작성 자는 그림 
5-11 에서 보여 준 계층과 같은 특정한 구성에 들어 가는 원천 및 목적파일의 계층을 규 
정 하는 Makefile 을 설 치한다. (그나 C ++ 에 있는 포함파일 들과 같은 보다 복잡한 의 존성 들 
역 시 make 에 의 해서 조종될수 있다. 프로그람작성 자에 의 해서 호출될 때 도구는 아래 와 
같이 동작한다. 사실상 다른 모든 조작체계들과 같이 UNIX 는 매개 파일에 날자와 시간 
을 붙혀 둔다. 원천파일에 대한 표식 이 금요일，7월 6일 오전 llh 24 min 이고 반면에 대응 
하는 목적 파일 에 붙은 표식 은 금요일, 7월 6일 오전 llh 40 min 이 라고 가정 하자. 그때 는 
목적 파일이 콤파일러에 의 해서 창조되였기때문에 원천파일이 변화되여야 한다는것은 명 
백하다. 다른 한편 만일 원천 파일 에 있는 날자와 시 간표식 이 목적파일 에 있는 날자와 시 
간보다 더 늦으면 그때 는 make 가 원천파일의 현재 판본에 대 응한 목적 파일의 판본을 창 
조하기 위하여 적 당한 콤파일 러 나 아쌤 블리 를 호출한다. 

다음에 수행적 재 가능한 프로그람에 있은 날자와 시 간은 그 구성 배 치 에 있는 매 개 목 
적파일 에 있는것 들과 비 교된 다. 만일 수행적 재 가능한 프로그람이 모든 목적파일 들보다 
더 늦으면 그때 는 다시 련결 할 필 요가 없 다. 그러 나 목적파일 이 수행적 재 가능한 프로그 
람보다 더 늦으면 그때 는 목적파일 에 대 한 최 신판본을 병 합하지 말아야 한다. 이 경 우에 
는 make 가 련결프로그람을 호출하여 갱신된 수행적재가능한 프로그람을 구축한다. 
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다른 말로 make 는 수행적재가능한 프로그람이 매개 모둘에 대한 현재의 관본을 병 
합하는가를 검사한다. 만일 그렇 다면 더 이상 아무것도 수행되지 않으며 CPU 시 간이 불필 
요한 를파일이나 련결에 랑비되지 않는다. 그러나 그렇지 않다면 그때는 make 는 련관된 
체 계 쏘프트웨어 를 호출하여 제 품의 최 신판본을 창조한다. 

이밖에 make 는 목적파일을 구축하는 과제를 간소화한다. 사용자에게 있어서 어느 모 
둘이 리용되며 그것들이 어떻게 련결되는가를 매번 명시할 필요는 없다. 왜냐하면 이러 
한 정 보가 이 미 Makefile 에 있기 때 문이 다. 그러 므로 단일 한 make 지 령 은 수백 개 의 모둘을 
가진 제 품을 구성하며 완성 된 제 품이 정 확하게 조립 되 였 다는것 을 담보하기 위하여 필요 
하다. 


5.10. CASE 기술들 리용한 생산성제고 

레 이 휘(문헌 [ Myers , 1992] 에 제 시 된바와 같이)는 CASE 기 술을 도입 한 결과로 인 
한 생 산성제 고에 대 한 연구를 진행하였 다. 그는 10여개 산업 분야의 45개 회 사들로부 
터 자료를 수집하였 다. 회 사들가운데 서 절 반은 정 보체 계분야와 관련되 여 있 고 25%는 
과학부문, 25%는 실시 간우주산업과 관련되 여 있다. 해마다 평균생산장성은 9%(실시 간 
우주산업 )부터 12%(정 보체 계 )사이 에 서 변화되 였 다. 만일 생 산성제 고만을 고려하게 된 
다면 이러한 수자는 CASE 기술을 도입하여 사용자당 12만 5천딸라의 가격을 얻게된 
다는것을 정 당화할수는 없다. 그러 나 조사된 회사들은 CASE 기술에 대한 정 당성 이 단 
순히 생 산성 을 제 고할뿐아니 라 개 발기 간을 보다 단축하고 쏘프트웨 어 의 품질 을 개 선 
한다고 보고 있다. 달리 말하면 그것 이 비 록 일 부 CASE 기 술의 제 안자들이 주장한것보 
다 적 다고 하더 라도 CASE 환경의 도입은 생산성을 제고하였다. 그럼에도 불구하고 쏘 
프트웨 어기업체들이 CASE 기술을 도입하는데는 그것이 개발을 더 빨리 하게 하고 오 
유가 더 적어 지게 하고 유용성을 더 높이며 유지정비를 쉽게 하고 사기를 더 높여 
주는것 과 갈은 기 타 다른 중요한 원 인들이 있다. 

15개의 세계 대기업체산하의 500개 회사들에서 진행한 100개이상의 개발프로젝트들 
로부터 제 기된 CASE 기 술의 효과성 에 대 한 새 로운 결과들은 교육과 쏘프트웨 어개 발공정 
의 중요성 을 반영 하고 있 다 [ Guinan , Cooprider , and Sawyer , 1997]. CASE 를 리 용한 림 에 
특정한 도구에 대 한 교육# 물론 일 반적 인 응용프로그람개 발을 위한 교육을 줄 때 사용 
자들의 요구를 더욱 충족시키게 되였고 개발일정을 맞출수 있었다. 그러나 교육이 진행 
되 지 않으면 쏘프트웨어 는 뒤 늦게 배 포되 고 사용자들의 요구는 더 욱더 만족시 키 기 어 렵 
다. 또한 림 이 CASE 도구를 구조화방법 론과 결 합하여 리용하면 성 능이 50%까지 올라 갔 
다. 이러한 결과들은 CASE 환경이 성숙준위 1, 2에 있는 그룹에 의하여 리용되지 말아야 
한다고 한 2.11 에서의 주장을 확증해 주고 있다. 사실대로 말한다면 머저리는 도구를 가 
지 고 있 어 도 여 전히 머 저 리 이 다 [ Guinan , Cooprider , and Sawye , 1997]. 

이 장의 마지막그림 인 그림 5-13 은 이 장에서 서술한 리론적 인 도구들과 CASE 도구 
들을 그것이 서술된 절들과 함께 자모순서로 렬거해 주고 있다. 
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리론적인 도구 

비용 대 리득분 
척도 (5.3) 

계단식 세련 (5.1) 

석 (5.2) 


CA 況: 분류 


환경 (5.5) 

하위 CASE 도구 (5.5) 

상위 CASE 도구 (5.5) 

작업대 (5.5) _ 

_ CASE 도구 

구축도구 (5.9) 

코드작성도구 (5.6) 

구성 조종도구 (5.8) 

일관성 검사기 (5.5) 

자료사전 (5.5) 

전자우편 (5.6) 

대면부검 사 (5.6) 

직결 문서작성 (5.6) 

조작체 계 앞단처 리 프로그람 (5.6) 
인쇄 프로그람 (5.6) 

보고서 생 성 프로그람 (5.5) 

화면 생 성 프로그람 (5.5) 

원천준위 오유수정 프로그람 (5 .句 
표처 리 프로그람 (5 .句 
구조편집기 (5.6) 

판본조종도구 (5.7) 

문서 처 리 프로그람 (5.6) 

WWW 열람기 (5 .句 _ 


그림 5-13. 이 장에서 서술한 리론적 인 도구들과 쏘프트웨 어 
( CASE ) 도구들 그리고 해당한 절 

O 야 

-U- 一 I 

첫째로 많은 리론적인 도구들이 있다. 밀러의 법칙에 기초한 계단식세련은 5.1 에서 
서술하고 례증하였다. 또 하나의 분석도구인 비용 대 리득분석은 5.2 에서 서술하였다. 쏘 
프트웨 어 척 도를 5.3 에 서 소개하였 다. 
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여 러 가지 를퓨터 지원쏘프트웨 어 공학 ( CASE ) 도구들은 5.4 부터 5.6 까지 에 서 서 술하였 다. 
큰 제품이 개발될 때는 판본조종，구성조종 그리고 구축도구들이 필수적이다. 이것들은 
5.7 부터 5.9 에 서 서 술하였 다. CASE 기 술을 리 용한 결 과로 인 한 생 산성 제 고는 5.10 에 서 서 
술하였다. 


보 충 

밀 러의 법 칙과 관련한 보충적 인 정 보를 얻기 위하여 그리고 콤퓨터두뇌 가 토막들에 
대 하여 어 떻게 동작하는가 하는데 대 한 그의 리 론을 알기 위하여 독자들은 밀 러의 최초 
의 론문 [ Miller , 1956] 은 물론 론문 [ Tracz , 1979, and Moran , 1981] 을 참고할수 있다. 인식 
원리와 콤퓨터과학의 견지에서의 밀러의 법칙의 분석은 문헌 [ Coulter , 1983] 에서 찾아 볼 
수 있다. 

계단식세련에 관한 워스의 론문은 이러한 종류의 대표적저서이며 주의 깊은 연구라 
고 말할수 있다 [ Wirth , 19 기]. 계단식세련의 견지에서 같은 의의를 가지는것은 디지크스트 
라 [Dijks 仕 a , 1976] 와 워스 [ Wirth , 1975] 가 쓴 책이다. 밀즈는 계단식세련을 통구조화설계 
즉 명세서로부터 설계를 작성하는 기법에 적용하였다 [ Mills , Linger , and Hevner , 1987; 
Mills , 1988]. 라즐리츠는 계단식세련을 대규모제품개발에로 확장하였다 [ Rajlich , 1985]. 실 
시간체계에 대한 계단식설계는 문헌 [ Kurki - Suonio , 1993] 에 서술되여 있다. 

CASE 에 대한 기사는 IEEE Software 1995년 3월호와 1996년 9월호에서는 물론 
Communications of the ACM 1995 년 6 월호에 소개되 였다. 문헌 [Chmura and Crockett , 
1995] 는 쏘프트웨 어개 발에 서 노는 CASE 도구의 역 할에 대 하여 검 토하였 다. 도구의 발전 
에 대한 실례 연구는 문헌 [ Kitchenham , Pickard , and Pfleeger , 1995] 에 서술되여 있 다. 

이 책 에서 는 쏘프트웨 어개 발공정의 개 별적 인 단계들을 위한 CASE 도구들은 매 단계 
를 설명하고 있는 장들에 서술되여 있다. 작업 대 나 CASE 환경에 대한 정보는 14장의 보 
충에서 참고할수 있다. 

문헌 [ Whitgift , 1991] 은 구성관리 에 대 한 좋은 소개도서 이 다. 쏘프트웨 어생명주기의 
선택 이 구성 배 치관리 에 주는 영 향은 문헌 [Bersoff and Davis , 1991] 에 서 서 술하고 있 다. 
쏘프트웨 어 구성 배치 관리 에 관한 국제 토론회 회 보는 구성관리 에 대 한 정 보의 유용한 원천 
으로 된다. 

비용 대 리득분석에 관해서는 문헌 [ Gramlich , 199기을 비롯한 좋은 책들이 많다. 
정 보체 계 에 적 용된 비 용 대 리득분석 에 대 한 정 보는 문헌 [King and Schrems ，1978] 
을 참고할수 있다. 척 도에 관한 중요도서들에 는 문헌 [Sheppard 1996, and Fenton and 
Pfleeger , 199 기들이 포함된다. 아주 상세 하게 쓴 책은 [ Grady , 1992] 이 다. 문헌 [ Johes ， 
1994 a ] 는 실현할수 없고 타당치 못함에도 불구하고 문헌에서 계속 언급되여 온 척도 
들을 강조하고 있 다. 객체지 향척도는 [ Henderson - Sellers , 1996] 에 서술되여 있 다. 1997 
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년 3 월과 4 월에 발표한 IEEE 此/ fMwe 에는 문헌 [ Pfleeger , Jeffrey , Curtis , and 
Kitchenham , 199 기을 비롯한 척도에 관한 많은 론문들과 쏘프트웨어척도에 대한 평가 
를 포함하고 있다. 

작은 프로젝 트에 대 한 척 도는 IEEE Software 1999 년 3 월/ 4 월 호에 서 론의하였 다. 척 도 
에 관한 많은 기 사들은 IEEE Computer 1994 년 9 월호와 IEEE Software 1997 년 3 월/ 4 월호 
에 있다. 


문 제 

5.1. 련속적 인 주파일갱 신문제의 수정된 세번째 세 련에 대 한 설계 에 전망 (/ oo 起/?心쐬 
을 도입한 효과를 고찰하시 오. 즉 하나의 트랜잭 션을 실현하기전에 다음트랜잭 션이 읽 어 
져야 한다. 만일 두개의 단일트랜잭션이 같은 주파일기록에 적용된다면 현재 트랜잭션의 
처리와 관련한 결정은 다음트랜잭션의 류형에 의존하게 된다. 행에는 현재의 트랜잭션의 
형 을 표시 하고 렬에는 다음에 오는 트랜잭 션의 형 을 표시한 3 X 3 표를 작성 하고 매 실례 
에서 취할 작용을 채워 넣으시오. 실례로 갈은 기록에 대한 두개의 련속적인 삽입은 반 
드시 오유로 된다. 그러나 두개의 변경은 완전히 타당할수 있다. 즉 실례로 신청자는 주 
어 진 달에 한번이상 주소를 변경시킬수 있다. 이제 전망을 결합한 세번째 세련에 대하 
여 흐름도를 작성하시오. 

5.2. 문제 5.1 에 대 한 대 답이 변경트랜잭 션에 뒤 이 은 삭제 트랜잭 션을 정 확하게 조종 
할수 있는가를 검토하시오. 이 두 트랜잭션은 동일한 주파일레코드에 적용된다. 만일 그 
렇 지 않다면 대 답을 수정하시 오. 

5.3. 문제 5.1 에 대한 대답이 삽입，변경에 뒤이은 삭제트랜잭션을 정확하게 조종할수 
있는가를 검토하시오. 이 트랜잭션블은 모두 동일한 주파일레코드에 적용된다. 만일 그렇 
지 않다면 대 답을 수정하시 오. 

5.4. 당신의 대 답이 n 개 의 삽입 과 수정，또는 삭제 ( n >2) 를 정 확히 조정 할수 있는가를 
검토하시오. 이 트랜잭션들은 모두 동일한 주파일레코드에 적용된다. 만일 그렇지 않다면 
대 답을 수정하시 오. 

5.5. 마지막트랜잭션기록은 뒤에 아무것도 가지고 있지 않다. 그림 5-1 에 대한 흐름 
도가 이것을 고려 하고 있으며 마지막트랜잭 션기록을 정확히 처 리 하는가를 검토하시 오. 
그렇 지 않으면 대 답을 수정하시 오. 

5.6. 일부 응용프로그람들에서 전망에 대한 변경은 트랜잭선를 잘 정돈함으로써 실현 
될수 있다. 실례 로 같은 주파일기 록에 대 한 변경 에 뒤 이 은 삭제 에 의하여 야기된다면 
원래의 문제는 수정되기전에 삭제를 진행하여 해결될수 있다. 이것은 주파일이 정확하 
게 작성 되 고 하나의 오유통보가 례외 보고서 에 나타나게 할것 이 다. 문제 5.2, 5.3 그리 고 
5.4 에 렬거된 모든 난점들을 해결할수 있는 트랜잭션의 순서짓기 가 존재 하는가를 조사 
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하시 오. 

5.7. 새로운 형의 위장질병 이 콘코르디 아 ( Concordia ) 나라(역자주; 가상적인 나라) 
를 휩쓸고 있다. 히스토플라즈마증과 마찬가지로 공기전염된다. 비록 질병이 치명적 
인것 은 아니 더 라도 그 병 균이 침습하면 매 우 고통스럽 고 약 2주일동안은 일할수 없 
다. 콘코르디 아정부는 아무리 많은 돈이 들더 라도 질병 을 근절하기 위하여 비 용을 
소비 하기로 결정하려고 한다. 대중건강부서와 의논할 책 임을 말은 위원회는 문제를 
네 가지 측면 즉 건강관리 비 용(콘코르디 아는 모든 시 민들에 게 건강관리 비 용를 무료로 
제 공하고 있다.), 수입 을 잃 은것(때 문에 세 금의 손실), 고통과 불안 그리 고 정 부에 대 
한 감사라는 네가지 측면을 고찰하고 있다. 비용 대 리득분석이 위원회를 어떻게 방 
조할수 있는가를 설명하시오. 얻어질 가격 또는 리득에 대하여 가격타산을 어떻게 
제 안하겠 는가? 

5.8. 1 인쏘프트웨 어제품개발에서는 판본조종도구를 필요로 하는가? 만일 그렇 다면 무 
엇 때문인가? 

5.9. 1 인쏘프트웨 어제 품개 발기 업체 에서는 구성조종도구가 필요한가? 만일 그렇 다면 
무엇 때문인가? 

5.10. 당신은 소형잠수함의 항해체계를 조종하는 쏘프트웨 어를 책임진 관리자이다. 
서 로 다른 사용자에 의하여 보고된 세개의 오유들을 수정하여 야 하는데 그것 을 각각 파 
운, 문린, 라첼에게 할당하였다. 하루후에 당신은 세개의 변경을 모두 실현하기 위해서는 
동일한 4 개 의 모둘이 변경 되 여 야 한다는것 을 알았다. 그러 나 당신의 구성 조종도구는 조 
작을 하지 않는다. 그러므로 당신은 자체 로 변경들을 관리해 야 할것 이 다. 그것을 어 떻게 
할것인가? 

5.11. 2.1 1에 서 는 성 숙준위 1, 2에 있 는 기 업 체 내에 서 CASE 환경을 도입하는것 은 거 의 
의미가 없다는것을 언급하였다. 이것이 왜 그런가를 설명하시오. 

5.12. 낮은 성 숙준위 에 있는 기 업체내 에 CASE 도구(개 발환경 에 반대되는)를 도입한 
효과는 무엇 인가? 

5.13. (과정안상 목표) 어떤 류형의 CASE 도구가 부록 1에서 서 술한 브로드렌즈지역 
아동병 원제 품을 개 발하는데 적 합한가? 

5.14. (쏘프 트웨 어공학독본) 교원 이 문헌 [ Wirth , 19기]에 대 한 복제본을 배 포할것 이 다. 
워 스의 방법 과 이 장에 서 서 술한 계 단식세 련 방법 사이 의 차이 를 렬 거하시 오. 
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제 6 장. 시 험 


쏘프트웨 어 생 명 주기 모형 들은 모두 통합단계 후와 유지 정 비 단계 전 에 흔히 개 별 적 인 시 
험단계를 포함하게 된다. 품질이 좋은 쏘프트웨어를 개발하려고 하는 견지에서 이것은 
전혀 위험한 일은 아니다. 시험은 쏘프트웨어개발공정의 중요한 구성요소이며 생명주기 
전반에 걸처서 수행되 여 야 할 활동이 다. 요구사항확정 단계 에서는 요구사항이 검 열되 여 야 
하고 명세 작성 단계 에서는 명세 가 검 열되 여 야 하며 쏘프트웨 어생산관리 계획은 이와 류사 
한 정밀조사를 거처야 한다. 설계단계는 모든 단계들에서 주의 깊게 검열할것을 요구한다. 
코드작성단계에서는 매 모둘들이 반드시 시험되여야 하며 제품전체는 통합단계에서 시험 
되여야 한다. 인수시험을 거친후에 제품은 설치되고 유지정비단계가 시작된다. 유지정비 
와 밀접히 결부되여 변경된 제품판본들에 대한 반복적인 검열이 진행된다. 

달리 말하면 단순히 그 단계의 마감에서 그 단계의 결과물을 시험 하는것은 충분하지 
못하다. 실례 로 명세 작성 단계 를 고찰하자. 명세 작성 림성 원들은 자기 들이 개 발하는 동안 
명세서를 자각적으로 량심적으로 검열해야 한다. 개발림이 몇주 또는 몇달후에 공정의 
초기단계에서 만들어 진 오유가 거의 모든 명세서를 다시 작성할것을 요구한다는것을 찾 
아 내기 위한 목적으로만 완전한 명세서를 개발하는것은 그리 쓸모가 없다. 그러므로 매 
단계의 마감에 보다 정연한 시험을 진행하는것을 비롯하여 매 단계를 진행하는 동안 개 
발림이 끊임없이 시험을 진행하는것이 필요하다. 


알고 싶© @제 

배 리 보엠 (Bany Boehm) 은 검 중과 타당성 에 대 하여 다음과 같이 정의 하였 다 [Boehn^ 1984a], 
검 중: 제품이 옳바로 구성되고 있는가? 

타당성: 정확한 제품이 구성되고 있는가? 


용어 검 증 (ver 까 carton) 과 타당성 (va&foft’on) 은 2장에 서 소개 되 였 다. 검 증은 해 당한 단 
계가 정확히 수행되였는가를 결정하기 위한 공정으로 간주된다. 즉이것은 매 단계의 
마감에 진행된다. 한편 타당성은 제품이 의뢰자에게 배포되기전에 진행되는 강력한 평 
가공정 이 다. 그 목적 은 제 품전체 가 명세서 를 만족시 키 는가를 결정하는것 이 다(약간 다른 
정의를 알고 싶으면 우의 《알고 싶은 문제》를 보시오.). 이 두 용어는 IEEE Software 
Engineering 용어소사전 [IEEE 610.12, 199이에서 이런 방법으로 정의되였지만 시험을 의 
미하는 용어 V&V 가 일반적으로 시험을 지적하기 위하여 리용됨에도 불구하고 단어 
《검증》과《타당성》은 이 책에서 될수록 적게 리용된다. 그 하나의 리유는 6.5 에서 
설명한바와 같이 단어 《검증》이 시험의 범위내에서 다른 의미를 가지기때문이다. 두 
번째 리 유는 《 검 증과 타당성》(또는 V&Y; verification and validation) 이 라는 말이 어 떤 
단계 를 검 열하는 공정 이 그 단계 의 끝까지 연기 될 수 있 다는것 을 의 미 하기때 문이 다. 반 
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대로 이러한 검열이 모든 쏘프트웨어개발과 유지정비활동과 병렬로 수행된다는것이 본 
질적으로 중요하다. 그러므로 V & V 이라는 말의 요구되지 않는 내포적의미를 피하기 위 
하여 용어 시험 이 리용된다. 

본질에 있어서 두가지 류형의 시험 즉 실행에 기초한 시험과 비실행에 기초한 시험이 
존재한다. 실례 로 작성된 명세서를 실행하는것은 불가능하다. 즉 유일한 대 안은 명세서 를 
될수록 주의깊게 심사하든가 그것 에 대 하여 어떤 형 식의 분석 을 진행하는것 이 다. 그러 나 일 
단 실행가능한 코드가 있으면 그것은 시험실례를 실행시킬수 있으며 즉 그것은 실행에 기 
초한 시험으로 된다. 그럼에도 불구하고 코드의 존재는 비실행에 기초한 시험을 배제하지 
않는다. 왜냐하면 앞으로 설명되는바와 같이 코드를 주의 깊게 심사하는것은 적어도 시험실 
례를 동작시킬 때만 한 량의 오유들을 로출시키게 되기때문이다. 이 장에서는 실행에 기초 
한 시험과 비실행에 기초한 시험에 대 한 원리를 서술하고 있다. 이 원리들은 10장부터 16장 
까지에서 적용되는데 여기서는 공정모형의 매 단계와 그것에 응용할수 있는 특정한 시험실 
천들에 대하여 서술한다. 이 책의 첫 《알고 싶은 문제》에서 서술한 오유들은 치명적인 결 
과를 초래한다. 다행 히 도 대 부분의 경 우에 잔류오유를 가진 쏘 프트웨 어 를 배 포하는 경 우에 
피해가 그리 크지 않다. 그러나 시험의 중요성을 지나치게 강하게 강조할수는 없다. 

6.1. 품질문제 

용어 품질아 M 섰均;)은 흔히 쏘프트웨어범위안에서 리용될 때 잘못 리해되게 된다. 결국 
품질은 어떤 종류의 우수성 을 의미하지 만 이것은 유감스럽 게 도 쏘프트웨 어공학자들이 의 도 
하는 의미 는 아니 다. 사실대 로 말하면 쏘프트웨 어개 발에서의 세 련된 기 교는 순전히 정 확하게 
기 능을 수행하는 쏘프트웨어 를 엄 으면 충분하다는것 이 다. 즉 우수성 은 우리 가 보통 현재 의 
쏘프트웨어기법 으로 가능한것 보다 높은 준위 에 있다는것 을 의미한다. 쏘프트웨어의 품질은 
제 품이 명세서 를 만족시키 는 정 도를 의 미 하고 있다(다음의 《 알고 싶은 문제》를 보시 오.). 


알고 싶 e @제 

용어 품질을(《우수한》또는《훌륭한》과 대립하여)《명세서에 충실하라.》라- -의미 
로 리용하는것은 공학 및 제조업과 같은，#야에서 현실적이다. 실례로 코카를라병 8산기 
업소에서 품질조종관리자들을 고찰해 보자. 품질조종관리자의 업무는 생 산흐름선ᅳ 따라 
생산되는 병들이나 깡통들이 모든 면에서 코카를라에 대하여 명세서를 만족시킨디.는것을 
담보하는것 이다.《우수한》코카콜라 혹은《훌륭한》코카콜라를 생산하려는 시」-는 그 
어디에■ 없다. 즉 유일한 목적은 바로 매개 코카콜라병 이나 깡통이 그 탄산음료ᄐ 대한 
규정한 회사의 규정(명세)를 엄밀히 준수하고 있다는것을 확중하는것이다. 

용어 품질은 자동차공업에서도 마찬가지로 리용된다. 품질이 첫째라는것은 지\ 날 포 
드자동차회사가 내세웠던 구호이다. 다른 말로 포드의 목적은 포드생산흐름선에기 나온 
매 승용차가 그 차에 대한 명세서를 철저히 준수하고 있다는것을 담보하는것이다. ♦ 일 
반적인 쏘프트웨어공학의 의미에서 말한다면 ♦용4는 모든 면에서 《 바그》가 표어야 
한다는것 이 다. 
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매 쏘프트웨 어전문가들의 과제는 항상 품질이 좋은 쏘프트웨 어를 담보하는것 이 다. 
그러나 쏘프트웨어품질보증 ( SQA ) 그룹은 쏘프트웨어품질과 관련한 추가적인 책임을 지고 
있 다. 


6. 1. 1. 쏘프트웨어품질보증 

SQA 그룹의 한가지 임무는 제품이 정확하다는것을 담보하는것이다. 더 정확하게는 
일 단 개 발자가 어 떤 단계 를 완성하면 SQA 그룹성 원들은 그 단계 가 정 확히 진행되 였 다는 
것을 검열해야 한다. 또한 제품이 완성될 때 SQA 그룹은 그 제품이 전체적으로 정확하다 
는것 을 검 열 해 야 한다. 그러 나 쏘프트웨 어품질 보증는 해 당한 단계 의 마감이 나 개 발공정 
의 마감에 진행하는 시 험 ( V & V ) 보다 더 앞서 진행 된다. 즉 SQA 는 쏘프트웨 어개 발공정 
그자체 에 적 용된 다. 실 례 로 SQA 그룹의 책 임 에 는 쏘프트웨 어 가 준수해 야 할 여 러 가지 규 
격들의 개 발은 물론 이 표준이 준수되 고 있다는것 을 담보하는 감시 절 차를 확립하는것 이 
포함된 다. 간단히 말하여 SQA 그룹의 역 할은 품질 이 좋은 쏘프트웨 어개 발공정 을 담보하 
고 그로 하여 품질이 좋은 제품을 담보하는것 이 다. 

6.1.2. 관리독립성 

개 발림 과 SQA 그롭사이 의 관리 독립 성 ( ma « agen ’ a / ittdepemieme ) 0 ' 중요한 문제 이 다. 즉 
개 발은 한명 의 관리 자에 의해서 관리 된다. 그리 고 SQA 는 또 다른 관리 자의 관리 하에 있 
으며 어 느 관리 자도 다른 관리 자를 지 배할수 없어 야 한다. 그 리유는 심 각한 오유들이 
모두 배포최종기한이 다가옴에 따라 너무 자주 제품에서 발견되기때문이다. 쏘프트웨어 
기 업체는 이제 만족스럽지 못한 두가지 선택가운데서 하나를 선택해 야 한다. 즉 제 품이 
제 시 간에 실현될수 있지 만 오유가 매 우 많아서 의 뢰 자들이 오유쏘프트웨어 와 씨 름질을 
하게 하든가 또는 개 발자들이 그 쏘프트웨어 를 수정할수 있지 만 그것 을 늦게 배 포하든가 
하는 두가지 경 우가 있 다. 어 쨌든 의 뢰 자들은 그 쏘프트웨 어 기 업 체 를 믿 지 않게 될 것 이 
다. 개 발을 책 임 진 관리 자는 오유쏘프트웨어 를 제 시 간에 배 포할데 대 한 결정 을 채 택하지 
말아야 하며 또한 SQA 관리자는 이후의 시험을 수행하고 제품을 늦게 배포할데 대한 결 
정을 채 택할수 없어 야 한다. 대 신에 두 관리 자는 두개의 선택가운데서 어 느것 이 쏘프트 
웨 어기 업체와 의뢰자들에게 가장 흥미 있는가를 결정할 권한을 가지고 있는 보다 상급인 
관리자에게 보고해야 한다. 얼핏 보면 개별적인 SQA 그룹을 가지는것은 쏘프트웨어개발 
에 드는 비용이 상당히 추가되는것으로 된다. 그러나 사실은 그렇지 않다. 추가적 인 비용 
은 결과적 인 리득 즉 품질 이 좋은 쏘프트웨어 에 비해서 상대적 으로 작다. SQA 그롭이 없 
으면 쏘프트웨 어개 발기 업체의 매 성 원들은 품질보증과 관련한 활동에 일정한 정 도로 망 
라되 여 야 한다. 어떤 개발기 업체 가 100명의 쏘프트웨어전문가들을 가지고 있는데 매 사 
탐들은 자기 작업시간의 30%를 품질보증활동에 바친다고 가정하자. 이대신에 100명의 성 
원들을 두개 의 그룹 즉 쏘프트웨 어개 발을 진행하는 70명 의 성 원들로 이 루어 진 그룹과 
…쇼를 책임진 30명의 성원들로 이루어 진 그룹으로 가론다. SQA 에 같은 량의 시간이 
돌려 지며 SQA 그롭을 지도하는 관리자에게만 추가적인 비용이 소비된다. 이제는 품질보 


152 



증과 독립적인 전문가들의 그룹에 의해 수행될수 있는데 이것은 SQA 활동의 기업체전반 
에 서 수행 될 때보다 품질 이 더 높은 제 품을 개 발할수 있 게 한다. 

매우 작은 쏘프트웨어회사 (4 명의 직원 또는 그보다 더 적은 직원을 가진)의 경우에 
는 개별적인 SQA 그룹을 가지는것이 단순히 경제적견지에서 리익이 없을수도 있다. 이러 
한 환경에서 할수 있는 가장 좋은 방도는 명세서가 이 명세서를 작성하는데 책임이 있는 
사람이 아닌 다른 사람에 의해서 검 열되 고 설계작성，코드작성 등에 대 해서도 이 와 류사 
한 방식 으로 검 열된다는것 을 담보하는것 이 다. 그 리유를 다음절 에서 설명한다. 

6. 2. 비실행에 기초한 시험 

문서를 작성해야 할 책임을 지닌 사람을 그에 대한 심사를 책임진 유일한 사람으로 
간주하는것은 좋은 생각이 아니다. 거의 모든 사람들은 어떻게 오유가 문서에 끼여 들어 
가는가를 잘 리해할수 없으며 따라서 오유가 심사에서 왜 발견되지 않는가도 잘 리해 할 
수 없다. 그러므로 심사과제는 문서의 원래작성자가 아니라 다른 사람이 진행하여야 한 
다. 이밖에 오직 한명이 심사를 하는것은 충분하지 못하다. 즉 우리는 문서를 여러번 읽 
고서도 다른 사람들이 즉시에 찾아 내는 뻔한 맞춤법오유를 발견해 내지 못하는 경우들 
을 체험하였다. 이것이 바로 관통심사회의나 검토와 같은 심사기법의 기초를 이루고 있 
는 원리이다. 이 두가지 류형의 심사에서 문서(명세서나 설계문서와 갈은)는 폭 넓은 기 
능을 가지고 있는 쏘프트웨어전문가들의 림에 의해서 주의 깊게 검열된다. 전문가림에 의 
한 심사의 우월성은 각이한 기능을 가진 동업자들이 오유를 발견할 기회를 증대시킨다는 
것이다. 이밖에 공동작업하는 기능 높은 사람들로 이루어 진 림은 흔히 긍정적인 효과를 
나타낸다. 

관통심사회의나 검토는 심사의 두 류형으로 된다. 그것들사이의 근본적 인 차이는 관 
통심사회의가 검토보다 더 낮은 단계이고 덜 형식적이라는것이다. 

6. 2. 1 . 관■심사회의 

관통심사회의를 진행하는 림은 4〜6명으로 구성할수 있다. 명세서관통심사회의 림은 
적어도 한명의 명세작성림대표，명세작성에 책임이 있는 관리자，의뢰자대표，개발의 다 
음단계 (이 경 우에 는 설 계 단계 )를 수행하게 될 림 의 대 표 그리 고 쏘프트웨 어품질 보증그룹 
의 대표로 구성 된 다. 다음절 에 서 설명하는것 처 럼 SQA 그룹성 원들은 관통심 사회 의 에 참가 
하게 된다. 관통심사회의림성원들은 중요한 결함들을 찾아야 하기때문에 높은 기술과 경 
험을 가진 성원들로 되여야 한다. 즉 그들은 프로젝트들에 부정적인 영향을 주는 결함들 
을 찾게 된다 [ New , 1992]. 

관통심 사회 의 를 위한 자료는 관계 자들이 준비할수 있도록 미 리 배 포되 여 야 한다. 매 
심 사자들은 자료를 연구하고 다음의 두 목록 즉 검 토하는 사람들이 리해하지 못하는 항 
목들의 목록과 심 사자들이 부정 확하다고 생 각하는 항목들의 목록을 작성한다. 
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6. 2. 2. 관■심사회의의 운영 

만일 관통심사회의가 잘 진행되지 않고 결함이 계속 나오면 SQA 대표는 큰 손실을 
입 기 때 문에 관통심 사회 의 는 SQA 대 표가 사회한다. 이 와 대 조적 으로 명 세작성단계 를 책 임 
진 대 표는 기 타 다른 과제 들에 착수하기 위하여 될수록 빨리 명세서들이 승인되 기 를 바 
랄수 있다. 의뢰자대표는 검토에서 발견되지 않는 일부 오유들이 인수시험단계에서 나타 
나게 되 며 따라서 의 뢰 자측에 더 는 비 용을 들이 지 않고 수정 된 다고 결정할수 있 다. 그러 
나 SQA 대 표는 가장 큰 리해 관계 를 가지 고 있 다. 즉 제 품의 품질은 SQA 그룹의 전문가적 
능력 에 대 한 직접적 인 반영 이 다. 관통심사회의를 사회하는 사람은 오유들을 발견하기 위 
하여 관통심사회의림의 다른 성 원들이 그 문서를 보도록 안내해 준다. 오유를 정정하는 
것은 림의 과제 가 아니며 순전히 그후의 정정 을 위하여 그것 들을 기록해 두는것 이 다. 이 
에 대 해서는 네 가지 리유가 있다. 

1. 위원회(즉 관통심사회의림)가 제한된 관통심사회의시 간내 에 진행한 정정은 필요한 
기법들을 습득한 개별적인 성원들이 진행한 정정보다 품질이 좋지 못한것 갈다. 

2. 5명의 성원들로 이루어 진 관통심사회의림 이 진행한 정정은 적 어도 개 별적 인 사 
탐들이 진행한 정 정만한 시 간이 걸린 다. 그러 므로 5명 의 참가자들에 게 지 불되 는 
로임을 생각할 때 비용은 5배 나 많이 든다. 

3. 오유이라고 표식한 모든 항목들이 사실상 부정 확한것은 아니 다.《 만일 그것 이 조 
개지지 않으면 그것은 수정할수 없다.》라는 주장에 따라서 림 이 완전히 정정된 
것을《수정》하려고 하는것 이 아니 라 오유에 대하여 잘 분석하고 실제적으로 문 
제가 있을 때에만 정정하는것이 더 낫다. 

4. 관통심사회 의에서 는 오유를 발견하고 정정하기 위한 충분한 시 간이 없다. 즉 관 
통심 사회 의 는 2 h 이 상 하지 는 않는다. 오유를 찾고 기 록하는데만 시 간을 들이 며 
오유를 정정할 시 간은 없다. 

관통심 사회 의 를 지 도하는데는 두가지 방법 이 있 다. 

첫번째는 어떤 관계 자가 지도하는것 이 다. 관계 자들은 명백치 않은 항목들과 그들이 
부정 확하다고 생 각하는 항목들의 목록을 제 시한다. 명 세작성 림대 표는 심 사자들에 게 무엇 
이 명 백하지 않은가를 밝히 며 실지 오유가 존재 한다는데 동의 하든가 또는 심 사자들이 무 
엇때 문에 실수했는가를 설명해 주면서 매 개의 질문들에 대 답하여 야 한다. 

검 토를 지도하는 두번째 방법은 문서를 가지 고 진행하는것 이 다. 그가 개 별적 이든 림의 
성원이든 문서 작성을 책 임진 사람은 검토자들이 자기들이 준비 한 설명문이든가 선전물에 
의한 설명문을 가지고 참견을 하면서 관계자들이 그 문서를 훑어 보게 한다. 이 두번째 방 
법 이 좀더 철저할수 있다. 이 밖에 문서를 가지 고 진행하는 관통심사회의 에서 제 기되는 기 본 
오유들은 제출자에 의해서도 발견되기때문에 이 방법은 보다 많은 오유들을 발견하게 한다. 
제출자들이 매 문장을 자주 읽는 과정 에 여 러번 읽을 때도 드러나지 않았던 오유들이 별 안 
간 명 백하게 될 수도 있 다. 심 리 학자들이 진행하는 어 떤 유익 한 연구는 명 세 관통심 사회 의 와 
설 계 관통심 사회 의 , 계 획 관통심 사회 의 , 코드관통심 사회 의 들을 비 롯한 모든 종류의 관통심 사 
회의를 진행하는 기 간에 언어적서술에 의 해서 흔히 오유가 발견되는 리유를 밝혀 줄것 이 다. 
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놀랍지 않게 보다 철저 한 문서 에 의한 심 사는 쏘프트웨 어검 토 및 심 사에 대 한 IEEE 규격 
(IEEE Standard for Software Reviews and Audits)[IEEE 1028, 199 刀에서 규정된 기 법 이 다. 

관통심 사회 의 사회 자의 중요한 역 할은 질 문을 유도하고 토론분위 기 를 조성 하는것 이 다. 
관통심 사회 의 는 대 화과정이 다. 즉 제 출자 한쪽측만이 지 시하도록 하는것 은 금물이 다. 관통 
심사회의가 관계자들을 평가하는 수단으로 리용되지 않는다는것도 중요한 문제이다. 만일 
그런 일이 발생한다면 회의사회자가 아무리 잘하려고 노력한다고 하더라도 관통심사회의 
는 점수따기식회의로 변질되여 오유들을 발견하지 못하게 된다. 검토되고 있는 문서를 책 
임 진 관리 자는 추천된 관통심사회의림의 한 성원이 다. 만일 이 관리 자 역시 관통심사회의 
의 성원들(특히는 제출자)에 대한 년중사업평가에 책임이 있다면 림의 오유발견능력은 약 
화되게 될것이다. 왜냐하면 제출자의 원래의 동기는 발견되는 오유의 수를 최소화하는것이 
기때문이다. 이러한 흥미 있는 모순을 방지하기 위하여 어떤 주어 진 단계를 책임진 사람 
은 그 단계를 위한 임의의 관통심사회의림성원을 평 가할 책 임을 직접 지지 말아야 한다. 

6. 2. 3. 검 토 

검 토는 설계와 코드를 시험할 목적 으로 파간이 처음으로 제 안하였다 [ Fagan , 1976]. 

검토는 관통심사회의를 훨씬 초월하며 5개의 형식적인 단계를 가지고 있다. 첫째로 
검토될 문서(명세서, 설계, 코드 또는 계획)에 대한 개괄 (ovem 切 v ) 은 그 문서작성을 책임 
진 어느 한 사람에 의해서 작성된다. 개괄회의마감에 문서는 관계자들에게 배포된다. 둘 
째 단계 즉 준비 단계 에 서 관계 자들은 문서 들을 상세하게 리해하려 고 애 쓴다. 빈도별 로 
정렬된 최근의 검토에서 발견된 오유류형들에 대한 목록은 훌륭한 수단으로 된다. 이러 
한 목록들은 림성 원이 오유가 제 일 많이 발생할수 있는 부분들에 집 중할수 있게 한다. 
셋 째 단계 는 ^ ^.( inspection ) °] P K 시 작되 면 한명 의 관계 자는 검 토림 성 원파 함께 문서 들을 
쭉 흙어 보고 매 항목들이 포함되여 있으며 매 부분들이 적어도 한번 취해 진다는것을 
담보한다. 그다음 오유찾기 가 개시된다. 관통심 사회 의방법 에서 와 마찬가지 로 목적은 오유 
를 찾고 문서 작성하는것 이지 그것들을 정정하는것은 아니 다. 그날중으로 검토림책 임 자 
(중재 자)는 수행 이 세심 히 수행되 고 있다는것을 담보하기 위한 검 토에 대 한 서면보고서 
를 작성 한다. 넷째 단계는 재 작업 ( renw 次) 인데 여기에서는 그 문서를 책 임진 사람이 서면 
보고서 에서 지 적된 모든 오유들과 문제들을 해 결한다. 마지 막단계 는 뒤조사 ( fo / fow - wp ) 이 
다. 중재 자는 문서 들을 뢰 치하기도 하고 오유로 잘못 표시된 항목들을 명백 히 함으로써 
제기된 매개의 단순한 문제점들이 만족하게 해결되였다는것을 담보해야 한다. 그 어떤 
새 로운 오유가 인입 되 지 않았다는것 을 담보하기 위하여 모든 수정 결과들이 검 열되 여 야 
한다 [ Fagan , 1986]. 만일 검 토된 자료의 5%이 상이 재 작업 되 였 다면 림 은 100% 재 검 토하기 
위하여 다시 소집 되 여 야 한다. 

검토는 4명으로 이루어 진 림에 의해서 지도되여야 한다. 실례로 설계검토의 경우에 
림은 중재자, 설계자, 실현자, 시험자로 구성된다. 중재는 검토림에서 관리자로도 되고 책 
임자로도 된다. 다음단계를 책임진 림의 대표는 물론 현단계를 책임진 대표도 있어 야 한 
다. 설계 자는 설계 를 작성하는 림 의 한 성원이 며 반면에 실현자는 개 별적 으로든지 림 의 
한 부분으로든지 설계 를 코드로 바꾸는것 을 책임 진다. 파간은 시 험 자가 시 험실례 를 보장 
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하는것을 책임진 어떤 프로그람작성 자이라고 제기하였다. 물론 시험 자는 SQA 그룹의 한 
성 원으로 되는것 이 더 낫다. IEEE 규격은 3〜6명의 관계 자들로 이루어 진 림을 구성할것 
을 권고하였 다 [ffiEE 1028, 1997]. 중재 자는 특정 한 역 할을 논다. 즉 그는 림 을 설계 에 로 
이 끌어 나가는 책 임 자 (/ eac / er ) 이 며 또한 발견된 오유에 대 한 서 면보고서 를 작성하는것 을 
책 임 진 기 록자 ( recorc / er ) 이 기 도 하다. 

검 토에서 필수적 인 구성 요소는 가능한 오유들에 대 한 검 열목록이 다. 실례 로 설계검 
토에 대한 검열목록은 다음과 갈은 항목들을 포함한다. 즉 명세서의 매개 항목이 충분하 
고도 정확하게 제기되였는가? 매개 대면부들에 대하여 실제의 인수와 형식적인 인수가 
대 응되 는가? 오유조종기구가 적 당하게 결 합되 고 있는가? 설계 가 하드웨 어자원과 호환가 
능한가 또는 설계 가 실제 적 으로 리용되 는것 이상으로 하드웨 어 를 요구하지 않는가? 설계 
가 쏘프트웨어 자원과 호환가능한가? 례하면 명세서 에 규정된 조작체 계 가 설계 에서 요구 
하고 있는 기능을 가지고 있는가? 하는것이다. 검토절차에서 중요한 구성요소는 오유통 
계 에 대 한 기 록이 다. 오유는 엄 격하게 (중요성 또는 부차성 에 따라서 중요한 오유의 한가 
지 실례 는 자료기 지 의 조기 종결 또는 손상을 초래하는 오유이다.) 오유류형별로 기 록하 
여 야 한다. 설계 검 토의 경 우에 전형 적 인 오유류형 에는 대 면부오유와 론리 적오유가 포함 
된다. 이러한 정보는 많은 유용한 방식으로 리용될수 있다. 

1. 주어 진 제품에서의 오유개수는 대비되는 제품에서 같은 개발단계에서 발견된 오 
유의 평균값과 비교될수 있으며 관리 자에게 무엇 인가 잘못되였다고 경고를 주고 
시 기 적절하게 오유정 정작업 이 진행 되 게 한다. 

2. 2개 또는 3개 의 모둘에 대 한 설계 검 토를 진행하여 특정한 류형 의 오유가 불균형 
적인 개수를 가진다는것을 발견하게 되면 관리자는 다른 모둘들에 대한 검열을 
시 작할수 있으며 오유정 정작업 을 진행한다. 

3. 만일 특정한 모둘에 대 한 설계검 토에서 제품에 있는 임의의 다른 모둘에서 발견 
된것보다 훨씬 더 많은 오유들이 발견되 면 보통 그 모둘을 처음부터 다시 설계해 
야 한다. 

4. 설계 검 토에서 발견된 오유의 개수와 류형 에 대 한 정 보는 림 으로 하여금 뒤단계 에 
서 갈은 모둘에 대 한 코드검 토를 진행할수 있게 한다. 

파간의 첫 번째 실험은 체계제품에 대하여 진행 되였다 [ Fagan , 1976]. 4명으로 된림이 
하루에 두 사람이 2 h 검 토하는 속도로 백명의 사람들이 lh 동안 검 토를 진행하게 하였다. 
제 품이 개 발되 는 기 간에 발견된 모든 오유들가운데 서 67%는 모둘시 험 이 시 작되 기전에 
검 토에 의하여 발견되 였다. 더우기 제 품이 설 치된 다음에 첫 7개 월동안 비 형 식적 인 관통 
심사회 의를 리용하여 심사된 비 교되는 제 품에서보다 검 토된 제 품에서는 38% 더 적은 오 
유가 발견되였다. 

파간은 응용프로그람제품에 대하여 또 다른 하나의 실험을 진행하고 발견된 모든 오 
유의 87%가 설계와 코드검토에서 발견되였다는것을 알아 내였다 [ Fagan , 1976]. 검토의 한 
가지 유용한 측면효과는 모둘시험 에 적은 시간이 들여 지기때문에 프로그람작성자의 능 
률 이 올라 가게 되 였 다는것 이 다. 자동화된 평 가모형 을 리용하여 파간은 검 토결 과 검 토에 
시 간이 걸 렸음에 도 불구하고 프로그람작성 자의 자원의 25%가 절 약되 였 다고 결정하였 다. 
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다른 실험 에서 존스는 발견된 오유의 70%이상이 설계 와 코드검 토를 진행하는 과정 에 발 
견되였다는것을 밝히였다 [ Jones , 1978]. 

이 후의 연구들에 서 마찬가지 로 흥미 있는 걸 과들이 얻 어 졌다. 6,000행 의 업 무자료 
처 리응용프로그람에 서 발견된 모든 오유의 93%는 검 토기 간에 발견되 였 다 [ Fagan , 1986]. 
문헌 [ Ackerman , Buchwald , and Lewski , 1989] 에서 보고된바와 같이 조작체계의 개발기 
간에 시험이 아니라 검토를 리용하는것은 오유를 발견하는데 드는 비용을 85%까지 감 
소시 켰 다. 례 하면 절 환체 계 제 품에 서 는 90%감소되 였 다 [ Fowler , 1986]. 분사식 발동기 연구 
소 ( JPL ) 에서는 평균 매 사람이 2 h 진행한 검 토에서 4개의 주요한 오유와 14개의 작은 
오유가 발견되였다 [ Bush , 1990]. 딸라로 바꾸어 환산하면 이것은 대략 한 검토당 2만 5 
천딸라를 절약한것으로 된다. 또한 다른 JPL 연구 [ Kelly , Sherif , and Hops , 1992] 에서는 
발견된 오유의 개수가 단계마다 지수함수적으로 감소한다는것을 보여 주었다. 달리 말 
하면 검 토수단을 리용하여 쏘프트웨 어개 발공정 에 서 신속하게 오유들을 발견 할수 있 었 
다. 이러한 신속오유발견의 중요성은 그림 1-5 에 반영되여 있다. 

검 토공정 에 서 위 험 요소는 그것 이 관통심 사회 의 와 마찬가지 로 성 능평 가를 위하여 
리용될수 있다는데 있다. 리용가능한 세부오유정보로 인하여 검토의 경우에 위험은 특 
히 심각하게 제기된다. 파간은 3년간에 걸치는 고찰을 통하여 자기가 그 어떤 IBM 관 
리 자도 프로그람작성 자에 대 하여 이 런 정 보를 리용하지 않으며 또는 그가 주장하는바 
와 같이 《목전의 리익을 위하여 장래의 리익을 희생시키》려고 하는 관리자도 없다 
는것을 알았다고 서술하는것으로써 이러한 우려를 가셔 냈다 [ Fagan , 1976]. 그러나 검 
토가 철저 히 진행 되 지 않으면 IBM 에서 와 같은 그러한 큰 성 과를 거둘수 없 다. 만일 
최 고관리 자측이 잠재 적문제 를 알아 차리 지 못하는 한 검 토정 보를 잘못 리용할 가능성 
이 명백 히 존재한다. 


6. 2. 4. 검토와 관통심사회의의 비교 

얼핏 보기에 검토와 관통심사회의사이의 차이는 검토림이 오유를 찾는데 도움을 주 
는 질문에 대 한 검 열목록을 리용한다는것 이 다. 그러 나 차이는 그보다 더 심오하다. 관통 
심사회의는 두 단계로 진행되는 과정이다. 즉 준비와 그것에 뒤이은 문서에 대한 분석이 
다. 검 토는 5단계 의 과정 즉 개 괄，준비，검 토, 재 작업，뒤조사로 이 루어 지 며 이 매 단계 
에서 지켜야 할 절차들은 형식화된다. 이와 갈은 형식화의 실례는 오유들을 주의 깊게 분 
류하고 그 정 보를 장래의 제품검토에서와 마찬가지 로 련속되는 단계들에서의 문서 에 대 
한 검 토에 리용하는것 이 다. 검 토과정 은 관통심 사회 의보다 시 간이 훨씬 더 오래 걸린 다. 
검 토가 추가적 인 시 간과 노력 을 보상할수 있는가? 선행한 절 에서의 자료들은 검 토가 오 
유를 발견하기 위한 강력 하고 비 용상 효과적 인 도구이라는것 을 명백 히 지적 하고 있다. 

6. 2. 5. 심사의 우결함 

심사(관통심사회의나 검토:)는 두개의 주요한 우점이 있다. 첫째로, 심사는 오유를 발 
견하는 효과적 인 방법 이 라는것 이 며 둘째 로, 오유가 쏘프트웨 어 개 발공정 의 조기 단계 에 서 
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즉 오유를 수정하는데 비용이 들기전에 발견된다는것이다. 실례로 설계오유는 실행단계 
가 개시되기전에 발견되고 코드작성오유는 모둘이 제품으로 통합되기전에 발견된다. 

그러 나 쏘프트웨 어개발공정 이 적당치 못하면 심사의 효과는 감소될수 있다. 첫째로, 
대규모쏘프트웨어는 보다 작고 독립적 인 구성요소들로 이루어 져 있지 않는 한에서는 심 
사하기가 아주 곤난하다. 객체지향파라다임의 우점의 하나는 정확히 수행되는 경우에 결 
과적인 제품이 실지로 독립적인 부분들로 구성된다는것이다. 둘째로, 설계심사림은 때때 
로 명세서를 참고해야 한다. 즉 코드심사림은 흔히 설계문서에 자주 접근할 필요가 있다. 
만일 선행 단계의 문서 작성 이 완성되지 않고 또한 프로젝트의 현재 판본을 반영 하도록 갱 
신되지 않으며 직결식으로 리용할수 없는한 심사림의 효과성은 심히 제한된다. 

6. 2. 6. 검토를 우 I 한 척도 

검 토의 효과성 을 결정 하기 위 하여 여 러 가지 각이 한 척 도가 리 용될수 있다. 첫째 가 
오유밀도(향 M // 쇼패/沙)이다. 명세서와 설계가 검토될 때 검토된 페지당 오유개수가 측정 
될 수 있다. 즉 코드검 토에 알맞는 척 도는 검 토된 코드 1,000행 당 오유개 수 ( KLOC ) 이 다. 
이러한 척도를 자료단위당 중요한 오유와 자료단위당 부차적인 오유로 가를수 있다. 또 
하나의 유용한 척도는 오유검 출률(/뇨// detection ra / e ) 이 다. 즉 시 간당 발견된 중요한 오유 
와 부차적 인 오유의 개 수이 다. 세 번째 척 도는 오유검 출효률(/뇨<// detection efficiency ) 즉 
한사람이 한시간동안 발견한 중요한 오유와 부차적 인 오유의 개 수이 다. 

비록 이 러한 척도들의 목적 이 검토과정에 대한 효과성을 측정하는데 있더 라도 반대 
로 결과는 개발림 의 결 함을 반영할수도 있다. 실례 로 만일 오유검 출률이 갑자기 
20 KLOC 로부터 30 KLOC 로 증가하였 다면 이것은 검 토림 이 갑자기 50%정도 더 효과적 으 
로 일했다는것을 의미하지는 않는다. 이것에 대한 다른 하나의 설명은 코드의 품질이 감 
소되였고 발견된 오유가 더 많아 졌다는것 이 다. 

비실행에 대한 시험을 론의하였으므로 다음의 문제점은 실행에 기초한 시험이다. 

6. 3. 실행에 기초한 시험 

시 험은 오유가 존재하지 않는다는것을 보여 주는것 이 라고 주장되 여 왔다. 오유 ( fauh ) 
는 일 반적 으로 바그必 wg ) 라고 하는것 에 대 한 IEEE 규격용어 이 며 반면 에 고장(/노은 오 
유의 결과로 하여 제품에 대하여 관측된 부정확한 동작이다 [IEEE 610.12, 1990]. 마지막 
으로 착오 ( error ) 는 프로그람작성 자에 의해서 이루어 진 잘못을 의 미한다.). 지 어 일부 기 
업체들이 쏘프트웨 어예산의 50%를 시험 에 돌린다고 해도 배포되는《시험된》제품은 
전적으로 믿을수는 없다. 

이러한 모순이 있게 되는 리유는 단순하다. 더지크스트라가 제기한바와 같이 《프로 
그람시험은 바그의 존재를 보여 주는 아주 효과적 인 방법 으로 될수 있다. 그러 나 그것은 
바그가 존재하지 않는다는것 을 보여 주는데는 기 대할수 없을 정 도로 부적 당하다.》 
[ Dijkstra , 1972]. 더 지 크스트라가 말하고 있는것 은 만일 어 떤 제 품이 시 험실례 를 리용하여 
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실행되고 그 출력이 잘못되였다면 그 제품은 결정적으로 어떤 오유를 포함하고 있다는것 
이다. 그러나 출력이 정확하다고 해도 제품에는 여러가지 오유가 있을수 있다. 즉 특정한 
시험으로부터 도출될수 있는 유일한 정보는 그 제품이 특정한 시험실례의 모임에 대하여 
정확히 동작하고 있다는것이다. 

6.4. 무엇이 시험되여야 하는가 

어떤 특성이 시험되여야 한다는것을 설명하려면 먼저 실행에 기초한 시험에 대하여 
정확한 설명을 주어야 한다. 

구데나흐에 의하면 실행에 기초한 시험은 선택된 입력을 리용하여 이미 알려 진 환 
경에서 부분적으로 제품이 실행된 결과에 기초하여 제품의 명백한 동작특성을 추론하는 
과정이다 [ Goodenough , 1979]. 이 정의에는 세가지 곤난한 의미가 포함되여 있다. 첫째로 
그 정의는 시험이 추론과정이라고 서술하고 있다. 시험자는 제품을 이미 알려 진 입력자 
료를 리 용하여 동작시 킨 다음 출력 을 시 험한다. 시 험 자는 제 품에 그 무엇 인가 잘못된것 
이 있는가를 추론해야 한다. 이러한 관점으로부터 시험은 널리 알려 져 있는 어두운 방 
에서의 검은고양이찾기와 비 교할수 있다. 시험 자는 어떤 오유를 찾는데 도움이 되는 실 
마리를 거의나 가지고 있지 못하다. 즉 10〜20개의 입 력 자료와 대응하는 출력자료의 모 
임 에 그리 고 혹시 사용자가 작성한 오유보고서 , 수행 되 는 코드만이 있을뿐이 다. 이 로부터 
시험자는 오유가 있는가，있으면 오유가 무엇인가 하는것를 추론해야 한다. 

정의 에서의 두번째 문제는《 이미 알려 진 환경》이 라는 표현으로부터 발생한다. 우 
리 는 사실 상 하드웨 어라든가 쏘프트웨어 와 갈은 우리 의 환경 에 대 하여 전혀 알수 없 다. 
우리는 절대로 조작체계가 정확히 기능을 수행하고 있다거나 혹은 실시간루린들이 정확 
하다는것을 확정할수 없다. 콤퓨터 의 주기억 에서 때때 로 장치적 인 고장이 있을수 있다. 
그래서 사실상 제품의 거동으로서 관측되는것 은 오유콤파일 러, 오유하드웨 어，환경 에서의 
어떤 다른 환경요소와 호상작용하는 정확한 제품일수 있다. 

실행에 기초한 시험에 대한 정의의 세번째 문제는《선택된 입력을 리용하여》라는 
표현이다. 실시간체계의 경우에는 흔히 체계의 입력에 대하여 그 어떤 조종도 할수 없다. 
항공우주학부문의 쏘프트웨어를 생각해 보자. 비행조종체계는 두가지 류형의 입력을 가 
진다. 첫번째 류형의 입력은 조종사가 비행기에 대하여 진행하려고 하는 동작이다. 결국 
만일 조종사가 올라 가려고 조종간을 뒤로 당긴다거나 혹은 비행기의 속도를 높이기 위 
하여 조절변을 연다고 하면 이런 기계적인 움직임은 수자신호로 변환되여 비행조종콤퓨 
터 에 보내 여 진다. 두번째 류형의 입 력은 비 행기의 고도라든가 속도 그리고 바람에 의해 
서 날개 가 흔들리 는 정 도 등과 갈은 현재 의 물리 적 인 상태 들이다. 비 행조종쏘프트웨어 는 
이러한 량들에 대한 값들을 리용하여 날개라든가 기관과 갈은 비행기의 구성부분들에 어 
떤 신호를 보내겠는가를 계산하여 지령을 실현한다. 조종사의 입력은 비행기의 조종에 
알맞게 설정됨으로써 쉽게 간단히 요구하는 값들로 설정될수 있는 반면에 비행기의 현 
재의 물리적인 상태에 대응한 입력은 그렇게 쉽게 조작될수는 없다. 사실상 비행기에 
《선택된 입력》를 제공할수 있는 방도는 없다. 그러면 이러한 실시간체계는 어떻게 시 
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는 조작자가 입력변수를 그 어떤 선택된 값 
시험의 목적이 실제적인 비행기기관에 불 
는작하여야 하는가를 결정하는것이라면 모의 
쏘프트웨어에 보내여 진 입력은 실제비행기 
과 구별할수 없게 된다. 출력에 대해서는 H 
I 출력 신호를 시 험 함으로써 분석 이 진행 된 I 
i 의 실제모형에 대한 훌륭한 근사로 될수 5 
는 될수 없다. 모의기를 리용하는것은 {S 
알려 진 환경이 모든 면에서 그 제품이 설 
三것을 의미한다(실시간쏘프트웨어를 시험하 
i 은 문제》를 보시오.). 


■분의 사람들，고 개발자들조차도 리해하기 복 
E . 일반적으로 발견할수 없는 요소들사이에서 - 
따라서 겉보기에는 중요치 않은 변화들이 아주 
I 유명한 실례% 1981년 4월에 첫 우주왕복선의 
다 [Garman 1981]. 우주왕복선은 4개의 동일한 운 
하나의 독립적 인 다섯번째 를퓨터가 4개의 를퓨 
il 된 다. 2년전에 우주왕복선의 콤퓨터 들이 동기3 
변경이 가해 졌다. 이러한 변경에서 하나의 유곡 
사간을 포함하고 있는 기록을 우주왕복선의 콤푸 
격에 잘못 보낸것이다. 이 시간은 이러한 오유가 
가까왔다. 약 1년후에 시간차이가 약간 커지게 
[는 정도로 되였다. 그다음 첫 우주왕복비행 이 국 
수개의 를퓨터들중 3개가 첫 를퓨터보다 한주기 
일 치하지 않으면 이 콤퓨터들로부터 오는 정義, : 
淨는 장애안전장치 가 다섯 번째 를퓨터 의 동기 화 
具으며 이로 하여 우주비행은 지연되였다. 이 주 
오유가 모선초기 화모듈에 있 었 다는것 이 다. 하 
사 않았던것이다. 


《 동작특성》에 대 하여 서 술하고 있다. 어 떤 
대답은 제품이 정확하게 기능하는가에 대한 
정확성은 필요조건도 충분조건도 아니다. 




대 하여 론의하기전에 4개 의 기 타 다른 동작특성 즉 유용성 과 믿 음성 , 로바스트성 그리 고 
성능을 고찰해 야 한다 [ Goodenough , 1979]. 


6. 4. 1 . 유용성 

유용성 均;)은 정 확한 제 품이 그 명세 서 에 허 용된 조건하에 서 리 용될 때 사용자들 
의 요구가 만족되는 정도를 의미 한다. 달리 말하면 정 확히 기능을 수행 하는 제품은 명세 
서에 의해서 타당한 입력에 복종한다. 사용자들은 다음과 갈은것들을 시험할수 있다. 즉 
제품을 리용하기 쉬운가, 제품이 유용한 기능을 수행하는가，제품이 경쟁하고 있는 제품 
들에 비해서 비용상 효과적인가를 시험할수 있다. 제품이 정확성여부에 관계없이 이와 
같이 중요한 문제들은 시험되여야 한다. 만일 제품이 비용상 효과적이지 못하면 그것을 
구입할 때 리익이 없다. 만일 제품을 리용하기 힘들면 그것은 전혀 리용되지 않거나 혹 
은 부정확하게 리용된다. 따라서 현존제품(수축포장된 쏘프트웨 어를 포함하여)의 구입을 
고려할 때 제품의 유용성을 우선적으로 시험하고 제품이 이런 점에서 만족되지 않으면 
시험을 중지한다. 

6. 4. 2. 믿음성 

제품에 대하여 시험해야 할 또 다른 한 측면은 믿음성이다. 

믿음성 ( retoM 均;)은 제품실패의 빈도와 위험성에 대한 측정값이다. 즉 실패는 허용되 
는 조작조건하에서 오유에 의해서 초래 되 는 받아 들일수 없는 효과나 동작이라는것 을 상 
기 하자. 달리 말하면 제 품이 얼 마나 자주 실패 하는가(실패사이 의 평 균시간)와 그 실패 의 
결과가 얼 마나 나쁜가 하는것 을 알아야 한다. 제 품이 실패될 때 중요하게 론의해 야 할 
문제 는 그것 을 퇴 치하는데 평 균 얼 마만한 시 간이 걸 리 는가 하는것 이 다. 그러 나 흔히 실 
패한 결 과를 뢰치 하는 시 간이 얼 마나 걸 리 는가 하는것 이 더 중요하다. 이 마지 막문제 점 
은 흔히 스쳐 버릴수 있다. 통신앞단에서 실행되고 있는 쏘프트웨어가 평균 6개월에 한 
번씩 실패한다고 가정하자. 그러나 그것이 실패하면 그것은 자료기지를 완전히 없애 버 
린 다. 기껏하여 자료기 지 는 마지 막검 사점 이 얻 어 졌을 때 자기 상태 로 다시 초기 화될 수 
있 으며 검 사흔적 은 자료기 지 를 그것 이 갱 신된 상태 로 두는데 리용될 수 있다. 그러 나 만 
일 이러한 회복공정이 자료기지와 통신앞단이 동작하지 않는 2일동안에 보다 좋은 역할 
을 수행 한다면 실패 사이 의 평 균시간이 6개 월 로 되 는데 도 불구하고 제 품의 믿 음성 은 낮아 
진 다. 


6. 4. 3. 로바스트성 

매 제품에 대하여 시험되여야 할 또 다른 하나의 측면은 로바스트성이다. 정확히 정 
의 하기 는 힘 들지 만 로바스트성은 본질 에 있어서 동작조건의 범 위 라든가 타당 
한 입 력에 대 한 접수할수 없는 결과가 발생할 가능성 그리 고 제품에 입 력되는 비타당한 
입력에 대한 허용가능성과 갈은 여러가지 요인들에 기인한다. 허용동작조건이 넓은 제품 
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은 보다 제 한된 제품보다 로바스트성 이 강하다고 말할수 있다. 로마스트적 인 제품은 입 
력이 명세서를 만족하는 경우에는 접수불가능한 결과를 산생시키지 말아야 한다. 실례로 
타당한 지령을 주는것은 해로운 결과를 초래하지 말아야 한다. 로바스트적인 제품은 그 
제품이 허용동작조건하에서 리용되지 않을 때에도 폭주되지 말아야 한다. 로바스트성의 
측면을 시험하기 위하여 명세서의 입력조건을 만족시키지 않는 시험실례를 일부러 넣어 
주고 시험자는 그 제품이 얼마나 나쁘게 작용하는가를 결정한다. 실례로 제품이 이름을 

요청 했을 때 시 험 자는 Control-A escape -%? $#@와 같은 허 용되 지 않는 문자렬 로 응답할 

수 있다. 만일 콤퓨터 가 Incorrect data-Try again 과 같은 통보문을 내 보내 거 나 더 좋기 는 

자료가 예 정된 규칙 을 준수하지 않고 있는 리유를 사용자에 게 알려 준다면 그것은 자료 

가 요구한것보다 약간 차이나도 폭주되는 제품보다는 로바스트성 이 더 강할것 이다. 

6. 4. 4. 성 능 

성능 ( performance ) 은 시험되여야 할 제품의 또 하나의 측면이다. 실례로 제품이 응답 
시간이 나 기 억공간요구와 관련한 제 약을 만족하는 정도를 알아야 한다. 반항공유도미싸 
일에 있는 콤퓨터와 갈은 내장형콤퓨터체계에 대한 기억공간제약은 주기억의 128 kB 만 
이 쏘프트웨어 에 리용될 수 있 다는것 과 같은것 일 수 있다. 쏘프트웨어 가 아무리 우월 하다 
고해도 만일 256 kB 의 주기억을 요구한다면 그때는 그 쏘프트웨어를 전혀 리용할수 없 
다(내 장형 쏘프트웨 어 에 대 하여 더 알기 위 해서 는 다음의 〈〈 알고 싶은 문제》를 보시 오.). 


알:2 싶 e ©제 

내장형를퓨터는 계산을 기본목적으로 하지 않는;체계의 필수적인 부분이 p 내장 
형쏘 프트웨 어의 기능은 콤퓨터가 내장되여 있는 장치들을 조종하는것이 다. 군사聲<;의 실 
례를 들어 보면 군용비행기안에 설치된 항공용를퓨터나 대륙간탄도미싸일에 설치」, 를퓨 
터들의 망이 있다. 미싸일의 원추형머리부에 있는 내장형를퓨터는 그 미싸일만을 표종하 
며 미싸일기지에 있는 병사들의 로임지불표를 인쇄하는메는 리용될수 없다. 보다 - - 알려 
진 실례는 수자식시계나 세탁기에 있는 를퓨터소편이다. 세탁기에 있는 소편은 점 든적으 
로 세탁기를 조종하는데 리용된다. 그 세탁기의 주인은 장부를 결산하는데는 소편- ■ 쓸수 
가 없다. 


실시 간쏘프트웨 어는 장치시 간제 약에 대하여 특징 지 어 진다. 즉 시 간제 약은 제 약을 
만족시키지 않으면 정보를 잃을수 있다는 특성을 가진다. 실례로 핵반응로조종체계는 핵 
의 온도를 표본화하고 10 s 마다 그 자료를 처리해야 한다. 만일 체계가 매 10 s 마다 온도수 
감장치로부터 중단신호를 조종할수 있을 정도로 충분히 빠르지 못하다면 그때는 자료를 
잃어 버리며 자료를 되찾을수 없다. 즉 체계가 온도자료를 받아 들이게 되는 다음번 시 
각에는 잃어 머린 자료가 아니라 현재의 온도를 읽게 된다. 만일 반응로가 녹음점상에 있 
으면 명세서에 규정된것처럼 련관된 모든 정보들이 수신되고 처리되는것이 중요하다. 모 
든 실시간체계들에서 성능은 명세서에 지적된 모든 시간제약을 만족시켜야 한다. 
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6. 4. 5. 정확성 

마지막으로 정확성에 대한 정의가 주어 질수 있다. 만일 제품이 허용되는 조건에서 
동작될 때 계산자원리용에 독립인 출력명세서를 만족시키면 제품은 정확하다고 한다 
[ Goodenough , 1979]. 달리 말하면 입력 명세서를 만족시 키는 입력이 주어 지고 제품에 필 
요한 자원이 모두 주어 지면 제품은 출력이 출력명세서를 만족시킨다면 정확하다. 

시험 그자체에 대한 정의에서와 같이 정확성 ( correc / new ) 에 대한 이 정의는 의미적으 
로 우려를 자아내고 있다. 제품이 아주 다양한 시험실례에 대하여 성공적으로 시험되였 
다고 하자. 이것은 이 제품을 접수할수 있다는것을 의미하는가? 유감스럽게도 그렇지는 
않다. 만일 제품이 정확하다면 그것은 제품이 명세서를 만족시킨다는것을 의미한다. 그러 
나 명세서 그자체가 부정확하다면 어떻게 되겠는가? 이러한 난점을 례증하기 위하여 그 
림 6-1 에서 보여 준 명세서를 고찰하자. 명세서는 정렬에 대한 입력이 n 개의 옹근수들의 
배렬 p 인 반면에 출력은 비감소순서로 정렬된 또 다른 하나의 배렬 q 이라는것을 서술하 
고 있다. 얼핏 보기에는 명세서가 완전히 정확한것처럼 보인다. 그러나 그림 6-2 에서 보 
여 준 방법 仕 icksort 를 고찰해 보자. 이 방법에서 배 렬 q 의 n 개 요소들은 모두 0으로 설정 
되 여 있 다. 이 방법 은 그림 6-1 의 명세서 를 만족시키 며 따라서 정 확하다. 


입력명세서: p : n 개의 옹근수의 배렬， n >0 

출력 명세서 : q : q [0 ]i 如 I ]호 …空인 n 개의 옹근수의 배 렬 


그림 6-1. 정렬에 대한 부정확한 명세서 


void trickSort (int p [], int q []) 

{ 

int i ; 

for ( i =0; I < n ; i ++) 
q [ i ]=0; 

} 

그림 6-2. 그림 6-1 의 명세서를 만족시키는 방법 trickSort 


무슨 일 이 일 어 나겠는가? 유감스럽 게 도 그림 6-1 의 명세 서 는 옳지 않다. 출력배 렬 
다의 원소들이 입 력배 렬 p 의 원소들에 대 한 재정 렬 이라는 서술문이 생 략되 였다. 정 렬 에서 
본질적인 측면은 그것이 재배치과정이라는것이다. 그리고 그림 6-2 의 방법은 명세서의 
이러한 요구를 반영하고 있다. 달리 말하면 방법 仕 ickSort 는 정확하지만 그림 6-1 의 명세 
서는 옳지 않다. 정정된 명세서를 그림 6-3 에 보여 준다. 
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입력 명세서: 

p : n 개의 옹근수의 배렬， n>0 

출력명세서: 

q : q [이쓿 用[1] ■■••실 q [ n - l ] 인 n 개의 옹근수의 배렬 


배렬 다의 요소들은 변경되지 않은 배렬 다의 


요소들의 교체 이다 


.立림 6-3. 정렬에 대한 정정된 명세서 

우의 실례로부터 명백히 명세서오유의 결과는 중요하다. 결국 명세서가 부정확하면 
제품의 정확성에 대하여 말할수 없다. 

어떤 제품이 정확하다고 하는 사실은 충분하지 않다. 왜냐하면 정확하다고 보여 준 
명세서 그자체 가 옳지 않을수 있기때 문이 다. 그러 나 그것 이 필요한가? 다음의 실례 를 고 
찰해 보자. 어느 한 쏘프트웨어기업체가 새로운 C++ 를파일러를 얻게 되 였다. 새로운 콤 
파일 러는 낡은 콤파일 러 에 비해서 lmin 동안에 2 배 나 많은 행 을 가진 원천코드를 번역할 
수 있으며 목적코드를 거의나 45% 더 빨리 실행할수 있으며 목적코드의 규모는 약 20% 
더 작다. 이밖에 오유통보문은 훨씬 더 명백하고 년간 유지정비와 갱신에 드는 비용은 
낡은 콤파일러에서의 절반도 안된다. 그러나 여기에 하나의 문제점이 있다. 즉 임의의 콜 
라스에 서 for 명 령 문이 나타난 첫 시 각에 를파일 러 는 거 짓 오유통보문을 인쇄한다. 따라서 
콤파일러는 정확치 않다. 왜냐하면 콤파일러에 대한 명세서는 원천코드에 오유가 있을 
때에만 암시적으로 혹은 명백히 오유통보문을 인쇄할것을 요구하고 있기때문이다. 콤파 
일 러는 확실히 리용할수는 있다. 즉 사실상 한 경 우를 제외한 모든 방법 에서 콤파일 러 가 
절 대 적 으로 리 상적 이 다. 더 우기 이 러 한 부차적 인 오유가 그다음의 해 제 과정 에 서 정 확할 
것 이 라는것 을 기 대하는것 은 아주 타당이다. 그러 는 과정 에 프로그람작성 자는 거 짓 오유통 
보문을 무시하는것 을 배우게 된다. 기 업 체는 부정 확한 콤파일 러 를 가지 고 일할수 있을뿐 
아니 라 만일 누군가가 그것 을 보다 낡은 정 확한 콤파일 러 로 교체할것 을 제 기하면 항의할 
것이다. 따라서 제품의 정확성은 필요조건도 충분조건도 아니다. 

우의 두 실례 는 약간 인위 적 이다. 그러 나 그것들은 정 확성 이 단순히 제 품이 명세 서 
에 대한 하나의 정확한 실현이라는것을 의미하고 있다. 달리 말하면 제품이 정확하다는것 
을 보여 주는것 보다도 시 험하는것 이 더 낫다. 실행 에 기 초한 시 험과 련관된 모든 난점 들 
에 대 처하여 콤퓨터 과학자들은 어 떤 제 품이 자기 의 사명 을 수행 하고 있 다는것 을 담보해 
주는 다른 방법 을 제 기 하기 위하여 시 도하였 다. 40여년이상 상당한 주의 를 끌어 온 이 와 
같은 한가지 비 실 행 에 기 초한 시 험 은 정 확성 증명 이 다. 

6.5. 시험과 정확성증명의 대비 

정확성증명은 제품이 정확하다는것 즉 달리 말하면 명세서를 만족시킨다는것을 보여 
주는 수학적기법이다. 때때로 이 기법을 검증이라고 부론다. 그러나 이미 강조한바와 같 
이 용어 검증은 흔히 정확성증명뿐아니라 모든 비실행에 기초한 기법들을 의미하는데 리 
용된다. 명백히 말하면 수학적인 절차는 정확성증명이라고 불리울것이다. 독자들에게 그 
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것 이 수학적 인 증명 과정 이 라는것 을 상기시 키 기 위 하여 ^ 3 "^{correctness proving ) 0 } 

라고 한다. 


6. 5. 1 . 정확성증명의 실례 

정 확성 을 어 떻게 증명하는가를 보기 위하여 그림 6-4 에서 보여 준 코드토막을 고찰 
해 보자. 코드와 등가인 흐름도표를 그림 6-5 에 보여 준다. 이제 우리는 코드토막이 정확 
하다는것을 보게 된다. 즉 코드가 실행된 다음에 변수 s 는 배렬 모의 n 개의 원소들의 합 
을 포함할것 이 라는것을 보자. 그림 6-6 에서는 하나의 단언이 매 명 령문의 앞뒤 
에 즉 문자 4부터 요로 표식된 위치에 놓인다. 즉어떤 수학적성질이 성립하는 매 위치 
에서 하나의 주장을 주었다. 

이제 이러한 매 주장의 정확성을 증명한다. 

입 력명세서 즉 코드가 실행 되 기전에 셨에서 성 립하는 조건은 변수 n 이 옹근수이 라는 
것이다. 즉 


A : ne { l , 2, 3, •••} (6.1) 

명백한 출력명세서는 만일 조종이 표에 이르면 변수 s 의 값이 에 기억된 n 개의 값들 
의 합이라는것 이 다. 즉 


H : s = y [0] + y [ l ] + … + y [ n - l ] (6.2) 

사실상 코드토막은 보다 강한 출력명세 서 에 관하여 정 확하다는것 이 증명 될수 있 다. 

H : k = n and .#*?= y [0] + y [ l ] + … + y [ n - l ] (6.3) 


int k , s ; 

int y [ n ]; 

k =0; 

s =0; 

while ( k < n ) 

{ 

s = s + y [ k ]; 

k = k + l ; 

} 

그림 6-4. 정확성이 증명된 코드부분 
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마지 막명 령 문에 대 한 본래 의 작용은 출력명세서 (6.3) 가 어 디 에서 부터 오는가를 물어 
보는것이다. 증명의 마감에서 그 질문에 대답할것을 요구한다. 즉 문제 6.10 과 6.11 을 보 
시오. 입력명세서와 출력명세서외에 증명과정의 세번째 측면은 순환을 위한 불변량을 제 
공하는것이다. 즉 하나의 수학적표현식이 순환이 0.1 또는 여러번 실행되였는가 아닌가에 
관계 없 이 점 그에 서 성 립 한다는것 을 증명하여 야 한다. 성 립 한다고 증명 될 순환불변 량은 
다음과 갈다. 


公: k ‘ n and s = y [0] + y [ l ] + … + y [ n - l ] (6.4) 

이 제 만일 입 력 명세서 (6.1) 가 점 셨에서 성 립 한다면 출력명세서 (6.3) 는 점 산에 서 성 립 
한다는것을 보여 준다. 즉 코드토막이 정확하다고 증명된다. 

처음에 값주기명령문 k — 0 이 실행된다. 이제는 조종이 점 요에 있게 되는데 여기서 
다음의 단언이 성 립한다. 즉 


B : k _^0 (6.5) 

더 정확하게 점 요에서 단언은 k =0 and ne { l , 1, 3, •••} 을 읽어야 한다. 그러나 입력 
명세서 (6.1) 는 흐름도표의 모든 점에서 성립 한다. 그러므로 and ne { l , 2, 3, •••} 은 지금부 
터는 생략된다. 

점 C 에 서 두번째 값주기 명 령 문 s — 0 로부터 다음의 단언 이 성 립한다. 

C : k =0 and s =0 (6.6) 

이제는 순환이 입력된다. 순환불변량 (6.4) 이 정말 정확하다는것이 귀납적으로 증명될 
것 이 다. 순환이 처 음으로 실행 되 기전에 단언 (6 .句이 성 립한다. 즉 k =0 이 며 s =0 이 다. 이제 
순환불변량 (6.4) 을 고찰하자. 단언 (6.6) 에 의해서 k =0 이 고 입 력 명세서 (6.1) 로부터 離_1이 기 
때문에 요구한바와 같이 km 이 라는것 이 나온다. 더우기 k =0 이기때문에 k - l = -1 로 되며 

따라서 (6.4) 에서의 합은 요구한바와 같이 비게 되고 s =0 으로 된다. 그렇기때문에 순환불 

변량 (6.4) 은 첫 순환이 입력되기전에 참으로 된다. 

이제부터는 귀 납의 가정단계 가 진행된다. 코드토막이 실행되 고 있는 어떤 단계 에서 
순환불변량이 성립한다고 가정하자. 즉 어떤 값 k 0 , O ^ ko ^ n 와 같은 k 에 대하여 실행은 
점 £) 에 있으며 다음의 단언이 성 립한다. 

公: ko^n and s = y [0] + y [ l ] + … + y [ k 0 - l ] (6.7) 

이 제 조종이 조건시 험 통을 통과한다. 만일 •어 면 가정 에 의하여 ko ^ n 이 기 때 문에 

kO = n 으로 된다. 귀 납의 가정 (6.7) 에 의해서 이것은 다음의 사실을 의미한다. 

H : ko^n and s = y [0] + y [ l ] + … + y [ n _ l ] (6.8) 

이 것 은 정 확히 출력 명 세 서 (6.3) 이 다. 

다른 한편 만일 조건검 사 1대층_ 이 실 패하면 그때 조종은 점 左)에 서 점 표로 넘 어 
간다. ko 은 n 보다 같거 나 크지 않기때문에 k Q <0 이며 (6.7) 은 다음과 같이 된다. 
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E : ko<n and Sr = y |0| + y [ l ] + … + y [ ko _ l ] (6.9) 

이제 명령문 s — s + y [ k 이이 실현되고 따라서 표에 있는 단언 (6.9) 로부터 다음의 단 
언 이 성 립한다. 


F : ko<n and s = y [0] + y [ l ] + … + y [ ko - l ] + y [ ko ] 

= y [이 + y [ l ] + … + y [ k 0 ] (6.10) 

다음에 실행 되 게 되 는 명 령 문은 ko ᅳ k 0 + 1이 다. 이 명 령 문의 효과를 보기 위 하여 
이 명 령 문이 실행되 기전 ko 값이 17이 라고 가정 하자. 그러면 (6.10 )i 있는 더 하기식 에서 
마지막항은 y [ l 刀로 된다. 이제 값、이 하나씩 증가되여 18로 된다. 합 s 는 변화되지 않 
는다. 따라서 더하기식에서 마지막항은 여전히 y [ l 기로 되는데 이것은 지금 y [ ko _ l ] 로 되 
여 있다. 또한 점 표에서는 ko < n 이 다. 값 ko 이 하나씩 증가한다는것은 부등식 이 점 G 에서 
성 립 하기 로 되 여 있 다면 그때 k «^ n 이 라는것 을 의 미한다. 결 국 ko 이 하나씩 증가한 결 과 
점 G 에 서 다음과 같은 단언 이 성 립한다. 즉 

G : ko<n and s = y [이 + y [ l ] + … + y [ k 0 - l ] (6.11) 

점 G 에 서 성 립하는 단언 (6.11) 은 가정 에 의하여 점 £) 에 서 성 립하는 단언 (6.7) 과 같 
다. 그러 나 점 Z ) 는 점 (?와 위상기 하학적 으로 동등하다. 달리 말하면 (6.7) 이 k = ko 에 대해 
서 점 Z ) 에 서 성 립 한다면 다시 점 Z ) 에서 k = ko + 1이 성 립한다. 순환이 k = 0 에 대 하여 

성 립 한다는것은 이미 보여 주었다. 귀 납에 의 해서 순환불변량 (6.4) 을 모든 k ， 에 

대 하여 성 립하는것 으로 된 다. 

이 제 남은것 은 순환종결 을 증명하는것 이 다. 처 음에 단언 (6.6) 에 의하여 노의 값은 0 
과 같다. 순환이 매번 반복되면 명령문 k ᅳ k + 1이 실행될 때마다 k 값은 하나씩 증가 
한다. 결국 노는 값 n 에 도달하여야 하며 이때 순환은 끝나며 s 의 값은 단언 (6.8) 에 의해 
서 계 산되 고 따라서 출력명세 서 (6.3) 를 만족하게 된 다. 

검 토를 위하여 입 력명세서 (6.1) 가 주어 졌을 때 순환불변량 (6.4) 이 순환이 0.1 또는 
그이상 실행될 때 에 성 립 한다는것 이 증명되 였 다. 더우기 n 번 반복한 다음순환이 끝나고 
그때 노와 s 의 값들은 출력명세 서 (6.3) 를 만족시 킨다는것 이 증명되 였 다. 달리 말하면 그림 
6-4 의 코드토막은 수학적으로 정 확하다는것 이 증명되 였다. 

6. 5. 2. 정확성증명의 실례연구 

정확성증명의 중요한 측면은 그것이 설계 및 코드작성과 결합하여 진행된다는것이다. 
디 지 크스트라가 제 기 한바와 같이 《 프로그람작성 자는 프로그람을 증명 하게 되 며 프로그 
탐을 협 력 하여 완성 하여 야 한다.》 [ Dijkstra ，1972]. 실례 로 순환이 설계 에 병 합될 때 순환 
불변량이 제시된다. 즉 설계가 계단식으로 세련되기때문에 불변량이 있게 된다. 이런 방 
법으로 제품을 개발하는것은 프로그람작성자에게 제품이 정확하다는 믿음을 주게 되며 
오유의 수도 감소되게 된다. 또한 디지크스트라는 다음과 같이 강조하였다.《프로그람의 
믿 음성 준위 를 올리 기 위한 유일 한 효과적 인 방도는 그것 의 정 확성 에 대 한 확실 한 증명 을 
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주는것 이 다.》 [Dijks 仕 a , 1972]. 그러 나 제 품이 정 확하다고 증명 되 였 다고 할지 라도 그것 은 
철저히 시험되 여 야 한다. 시험을 정 확성증명과 결합하여 진행해 야 할 필요성을 설명 하기 
위하여 다음의 사실 을 고찰해 보자. 

1969년에 나우르는 제품을 구성하고 그 정확성을 증명하기 위한 기법에 대하여 보고 
하였다 [ Naur , 1969]. 이 기법은 나우르가 행편집문제 (// ne-e 소 jwoWem ) 이라고 명명한문 
제 에 의하여 례 증되 였 다. 즉 오늘날에 와서 이 문제 는 본문처 리 문제 로 고찰되 고 있 다. 그 
에 대 하여 다음과 같이 말할수 있다. 즉 

본문은 공백 문자나 행 바꾸기 , 문자에 의하여 분리 된 단어 로 이 루어 진 본문이 주어 지 게 

되 면 그것 은 규칙 에 따라서 행별형 식 으로 변환된다. 

1. 행은 다만 공백문자나 행바꾸기문자가 있는 위치에서 끝난다. 

2. 매행은 될수록 길게, 멀게 채워 진다. 

3. 행에는 최대위치 ( maxpos ) 이상의 문자들을 포함하지 않는다. 

나우르는 이 기법을 리용하여 처리절차를 구성하고 비형식적으로 그것의 정확성을 
증명 하였 다. 절 차는 ALGOL 60 언 어 상에 서 대 략 25개 행 으로 구성 되 였 다. 이 에 대 한 론문 
은 그다음 레 웬워 스에 의 해서 안 jg 잡지 에서 검 토되 였다 [ Leavenworth , 1970]. 

심사자는 나우르의 절차의 출력에서 첫 단어가 maxpos 문자만큼 길지 않으면 첫행의 첫 
단어는 공백 으로 채워 진다고 지적하였 다. 비록 이것 이 사소한 오유인것 같지 만 그것은 
시험된 절 차 즉 정 확하다고 증명된 자료가 아니 라 시 험실례 로서 실행된 절차로서 발견된 
오유이다. 런던은 나우르의 절 차에 서 3개 의 추가적 인 오유를 발견하였 다 [ London , 19기]. 
하나는 이 절차가 maxpos 문자보다 더 긴 단어를 만날 때까지 종결되지 않는다는것 이 다. 
또한 이 오유도 이 절차가 수행되였다면 발견되였을것이다. 런던은 그다음 정확한 판본 
의 절차를 작성 하고 그것 이 정 확하다는것을 형 식적 으로 증명하였다. 반면에 나우르는 비 
형 식적 인 증명 기 법 만 리용하였던것 이 다. 

다음의 일화는 구데나우와 게르하르트가 런던이 형식적인《증명》을 하였음에도 불 
구하고 그가 발견하지 못했던 3개의 오유를 발견하였 다는것 이 다 [Goodenough and Gerhart , 
1975]. 이러한 오유들에는 마지막단어의 뒤에 공백이나 행바꾸기문자가 놓이지 않으면 
출력 으로 될수 없다고 하는것 도 있 다. 다시 합리 적 인 시 험실례 를 선택하여 이 오유를 그 
리 어렵지 않게 발견하였다. 사실상 레웬워스와 런던 그리고 구데나우와 게르하르트가 
발견한 7개의 오유들가운데서 4개는 나우르의 원래의 론문에서 보여 준 례증에서와 같은 
시 험실례 를 실행 시켜 간단히 발견하였 다. 이 로부터 찾게 되 는 교훈은 명 백하다. 제 품은 
정 확하다고 증명되 였다고 해도 여전히 철저 히 시 험하여 야 한다는것 이 다. 

6.5.1 의 실례 는 지 어 작은 코드토막의 정 확성증명 이 오랜 과정 으로 될수 있 다는것 을 
보여 준다. 더우기 이 절의 실례연구는 25개행의 절차에서조차 정확성증명이 어렵고 오 
유를 범하기 쉽다는것을 보여 주었다. 그러므로 다음의 문제점이 제기된다. 즉 정확성증 
명 이 흥미 있는 연구착상으로 되는가 혹은 시기적절한 위력한 쏘프트웨 어공학기 법 인가 
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하는것이다. 이에 대한 대답은 다음절에서 보기로 한다. 

6. 5. 3. 정확성증명과 쏘프트웨어공학 

많은 쏘프트웨 어 공학실 천 가들은 무엇 때 문에 정 확성 증명 이 표준쏘프트공학기 법 으로 
간주되지 말아야 하는가 하는 리유를 제기하고 있다. 첫째로 그것은 쏘프트웨어공학자들 
이 수학적으로 충분히 숙련되지 못했다는것 이다. 둘째로 증명은 너무 비용이 들어서 실 
현할수 없다는것이다. 셋째로 증명은 아주 힘들다는것이다. 이러한 리유들은 지나치게 간 
소화되여 있다고 본다. 

비록 6.5.1 에서 보여 준 증명이 고등중학교 대수보다도 더 힘들게 리해될수는 없다고 
하더 라도 중요한 증명 들은 입 력 명 세 서 와 출력 명 세 서 , 순환불변 량들이 1 계 술어 계 산 또는 
2계 술어계 산 또는 그것 과 등가인 계 산으로 표현되 여 야 한다는것 을 요구하고 있다. 이 것 
은 다만 수학자들에게 있어서 증명과정을 더 간단하게 만들뿐아니라 정확성증명을 를 
퓨터 에 서 진행할수 있게 한다. 문제 를 좀더 복잡하게 한다면 술어계 산이 지 금에 와서 약 
간 뒤떨어 진것이라는것이다. 동시발생제품의 정확성을 증명하기 위해서는 시상론리나 
기타 다른 양상론 리를 리 용한 기법이 필요된다 [Manna and Pnueli , 1992]. 정확성 증명이 
수리 론리 에 대 한 숙련 을 요구한다는것 은 의 심할바 없 다. 다행 히 도 오늘날 대 부분의 콤퓨 
터과학전공부문들에서는 정확성증명기술을 전문으로 배우는것을 필수적 인 과정으로 또는 
배 경 으로 하고 있 다는것 이 다. 그러 므로 대 학들에 서 는 지 금 콤퓨터 과학졸업 생 들에 게 정 확 
성증명을 위한 충분한 수학적지식을 주도록 하고 있다. 지난 시기에는 실천에 종사하는 
쏘프트웨 어공학자들은 수학적 인 숙련을 반드시 필요로 하지 않는다는 주장이 사실 이였지 
만 오늘날 해마다 수천명의 를퓨터과학전공학생들이 산업에 망라되고 있는 실정에서는 
그러 한 주장을 더 이 상 할수 없게 되 였 다. 

쏘프트웨 어개 발에 서 증명 을 리용하기 에 는 너 무 비 용이 든다고 하는 주장도 잘못되 였 
다. 이와 대비적으로 정확성증명이 가지는 경제적인 생활력은 매 프로젝트의 기초는 비 
용 대 리 득분석 을 리용하는것 이 라는것 으로써 알수 있 다 (5.2). 실례 로 NASA 우주정 류소에 
대한 쏘프트웨어를 생각해 보자. 인간이 위험에 처해 있고 만일 그 무엇인가 고장났다면 
우주비행선구원단은 제때에 도착 못할수 있다. 생명에 결정적으로 관계되는 우주정류소 
쏘프트웨어 의 정 확성 을 증명하는데는 많은 비 용이 든다. 그러 나 정 확성증명 이 실행 되 지 
않는 경 우에 무시 될수 있는 쏘프트웨어 오유의 잠재 적 인 비 용은 매 우 크다. 

세번째 주장은 정확성증명이 매우 어렵다는것이다. 이러한 주장이 있음에도 불구하 
고 조작체계의 핵심부와 콤파일러，통신체계들을 비롯한 많은 중요한 제품들에 대하여 
성 과적 으로 정 확성 이 증명 되 였 다 [ Landwehr , 1983; Berry and Wing , 1985]. 더 우기 정 리 증 
명프로그람과 같은 많은 도구들이 정 확성증명 에 리용되 고 있다. 정 리증명프로그람들은 
제 품과 그것 의 입 출력명세서 와 순환불변 량들을 입 력 으로 취 한다. 그다음 정 리증명프로그 
탐들은 입력명세서를 만족시키는 자료를 입력하였을 때 출력명세서를 만족시키는 출력자 
료가 생성된다는것 을 수학적 으로 증명하게 된다. 

이 와 동시 에 정 확성증명 과 관련한 일부 난점 들도 있다. 실례 로 정 리증명프로그람이 
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정확하다는것을 어떻게 믿을수 있는가? 만일 정리증명프로그람이 《이 제품은 정확하 
다.》라고 인쇄하면 그것 을 믿 을수 있는가 하는것 이 다. 극단한 경 우에 그림 6-7 에 보여 
준 이 른바 정 리 증명프로그람을 생 각해 보자. 

아무리 코드가 이 정 리증명프로그람에 복종한다고 해 도《 이 제 품은 정 확하다.》고 
인쇄할것 이 다. 달리 말하면 정 리증명프로그람의 출력 에 대 하여 어 떻게 믿을수 있는가? 한 
가지 제 안은 바로 정 리증명프로그람이 그자체 에 복종하며 그것 의 정 확성 여부를 보여 준 
다는것 이 다. 원리적 인 의 미를 떠나서 이것 이 동작하지 않는다는것을 보여 주기 위 한 간 
단한 방도는 그림 6-7 에 서 보여 준 정 리증명프로그람이 증명 에 서 그자체 에 복종한다고 
하면 어 떤 일 이 일 어 나겠는가 하는것 을 고찰하는것 이 다. 언제 나 그러 하듯이 정 리 증명프 
로그람은《 이 제 품은 정 확하다.》고 인쇄하며 이 로부터 《 증명》은 그자체 의 정 확성 을 
증명하고 있다. 보다 더 난점으로 되는것은 입력명세서와 출력명세서 그리고 특히 양상 
론리와 갈은 기 타 다른 론리에서 순환불변량이나 그것의 등가물들을 찾아 내는것이다. 
이제 제품이 정확하다고 하자. 만일 매 순환에 대하여 적당한 불변량을 찾을수 없으면 
그 제품에 대 하여 정 확성을 증명할 방도는 없다. 도구들이 이 러한 과제 에 도움을 준다. 
그러 나 첨 단도구를 가지 고서 도 쏘프트웨 어공학자들은 정 확성 을 증명하지 못할수도 있 다. 
이러한 문제에 대하여 한가지 해결책은 6.5.2 에서 주장한바와 같이 제품개발과 증명을 병 
렬적 으로 진행하는것 이 다. 순환을 설계할 때 그 순환에 따르는 불변량은 동시 에 규정된 
다. 이러한 방법으로 코드모둘이 정확하다는것을 증명하는것이 좀 더 쉽다. 

void theoremProver () 

{ 

print “This product is correct ” ; 

} 

그림 6-7. 《정리중명프로그람》 

순환불변량을 찾아 낼수 없다고 하는것보다 더 나쁜 경우로서 만일 명세서 그자체가 
부정확하다면 어떻게 되겠는가? 이것에 대한 실례가 방법 仕 ickSort 이다(그림 6-2). 그림 
6-1 의 부정 확한 명세서 가 주어 진 경 우에 어 떤 좋은 정 리증명프로그람은 의 심할바없이 
그림 6-2 에서 보여 준 조작이 정확하다고 선언할것 이다. 

만나와 왈딩거는《우리는 절대로 명세서가 정확하다고 믿을수 없다.》，《우리는 절 
대 로 검증체 계 가 정 확하다고 믿을수 없다.》라고 서술하였 다 [Manna and Waldinger , 1978]. 
이와 같은 두명의 우수한 전문가들의 서술은 이전에 이야기된 여러가지 문제들을 모두 
포함하고 있다. 

이 모든것 이 쏘프트웨 어공학에 서 정 확성증명 이 차지할 자리 가 없 다는것 을 의 미하는 
가? 그러 나 그 답변은 이 와 아주 대 조적 이 다. 제 품의 정 확성 을 증명하는것 은 중요하며 
때 로는 사활적 인 쏘프트웨어도구로 된다. 증명은 인간이 위기 에 처하게 되는 곳에서 또 
는 반대로 비용 대 리득분석이 필요한 곳에서 적합하다. 만일 쏘프트웨어정확성을 증명 
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하는데 드는 비용이 제품이 실패한 경우에 드는 비용보다 더 적으면 그때는 제품에 대하 
여 증명해야 한다. 그러나 본문처리기의 경우의 연구에서 보여 준바와 같이 증명 그 하 
나만으로는 충분하지 않다. 대신에 정확성증명은 제품이 정확한가를 시험하는데 리용되 
는 그러한 기 법모임의 중요한 구성부분으로 볼수 있다. 쏘프트웨 어공학의 목적 이 품질이 
좋은 쏘프트웨 어를 생산하는것 이기때 문에 정 확성증명은 실지 로 중요한 쏘프트웨 어공학기 
법으로 된다. 지어 전체적으로 형식적인 증명이 정당하지 못할 때에도 쏘프트웨어의 품 
질은 비형식적인 증명을 리용하여 현저하게 개선될수 있다. 실례로 6.5.1 에서와 류사한 
증명 은 순환이 정 확한 회 수만큼 진행 된 다는것 을 검 열하는데 도움을 줄수 있을것 이 다. 쏘 
프트웨어 의 품질 을 개 선하기 위한 두번째 방도는 그림 6-6 에 서 와 같이 코드에 단언을 삽 
입 하는것 이 다. 만일 실행할 때 어떤 단언이 성 립하지 않으면 제 품은 개 발이 중지될것 이 
며 쏘프트웨어림은 실행을 종결시킨 그 단언이 부정확한가 혹은 실지로 그 단언을 동작 
시킴으로써 발견된 코드에서의 오유가 실지로 존재하는가를 조사할수 있다. Eiffel [ Meyer , 
1992 b ] 과 같은 언어들은 assert 명 령 에 의 하여 단언을 직 접 지 원한다. 이제 비 형 식적증명 
이 변수 xxx 의 값이 코드의 특정한 곳에 서 정 수이 여야 한다는것 을 요구한다고 하자. 지 
어 설계림이 xxx 에 대하여 부수로 될수가 없다는것을 확인한다고 해도 더욱 믿을수 있도 
록 코드의 해당한 곳에 명령문 


assert ( xxx 〉0) 


이 서 술되 여 있 어 야 한다는것 을 규정할수도 있 다. 만일 XXX 가 0보다 작거 나 갈으면 실 행 
은 끝나고 그다음 쏘프트웨어림이 이런 상황을 조사할수 있다. 유감스럽게도 C ++ 에서 
Assct 방는 C 에 서 assert ^ 류사하게 하나의 오유수정명 령 문이다. 즉 그것 은 언어 그자체 의 
일부분은 아니 다. Ada 95 에서는 단언을 pragma 로 서술하고 있 다. 


알:2 싶은 ©제 

Java 와 Ada (그러 나 C, C++ 는 아니 다.)와 같은 언어들에서 한가지 특징은 속빅 잠사이 
다. 속박검사의 한가지 실례는 매 배렬첨수들이 그것이 선언된 범위안에 있다는것- _ 담보 
하는것 을 실행기 간에 시 험하는것 이 다. 또 다른 실례는 부분적 인 범위검사 폭 어 13 값이 
어떤 변수에 할당될 때 그 값이 특정한 선언령 역안에 있다는것을 실행할 때 검시 :화는것 
이 다. 호아 (Hoare) 는 제품이 개 발되% 기 간에# 속박검사를 리 용하고 일단 제품이 장 확히 
동작하면 그만두는것은 물이 없는 땅에서 구명옷을 입고 헤염치기를 배우고 실지 4다에 
나가서 는 구명 옷을 벗 어 버리 는것 과 류사할수 있 다는것 을 제 안하였 다. 호아는 다기 가 
1961 년에 개 발한 ALGOL60 에 대 한 를파일 러를 서 술하였다 [Hoare, 1981]. 사용자들ᄐ 게 후 
에 이 를파일러의 최종판본이 설치된후에 속박검사를 그만둘 기회가 제공되였을 때 그 
들은 한결같이 그것을 거절하였다. 왜냐하면 그들이 를파일러의 초기판본의 실행- ' 검사 
하는 기간 값들이 범위를 벗어 나는 경우를 수많이 체험하였기때문이다. 

속박검# fe . i 다 일반적:인 개념인 단언검사의 특수한 경우로서 볼수 있다. 호「의 구 
명옷류추는 일 단 최종판본이 설치되면 단언검사를 그만두는데 마찬가지 로 리용될주 있다. 
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일단 사용자들이 제품이 정확하게 동작하고 있다고 확신하면 그들은 단언검사를 그 
만두도록 설정해야 한다. 이렇게 하면 실행은 빨리 진행되지만 단언검사가 중지된 경우 
에 단언에 의해서 발견될수 있는 오유들을 찾아 낼수 없게 된다. 그러므로 제품이 의뢰 
자의 콤퓨터에 설치된 다음이라도 실행시간에 대한 효과성과 단언검사를 계속하는 문제 
사이에는 절충을 해야 한다(이 문제에 대하여 흥미가 있다면 우의 《알고 싶은 문제》를 
보시 오). 

실행에 기초한 시험에서 근본적인 문제는 쏘프트웨어개발림성원들이 그 수행을 책 
임져야 한다는것이다. 

6.6. 실행에 기초한 시험은 누가 진행해야 하는가 

이제 프로그람작성자가 자기가 작성한 모둘을 시험해 줄것을 부탁한다고 가정하자. 
메이어는 시험을 오유를 발견할 목적으로 제품을 실행시키는 공정으로 서술하였다 [ Myers , 
1979]. 그러므로 시험은 하나의 파괴과정 이 다. 다른 한편 시험 을 진행하는 프로그람작성 
자는 보통 자기 의 창조물을 파괴하려 고 하지 않는다. 만일 코드에 대 한 프로그람작성 자 
의 기본태도가 일반적 인 보호적인 태도라고 하면 프로그람작성 자가 오유를 밝혀 줄 시험 
실례 를 리용하는 기회 는 기 본동기 가 실지 제 품을 파피 하는것 이였을 때 보다 현저 히 더 작 
다. 시험이 성공적이라는것은 오유를 찾는것이다. 이것 역시 난점을 가지고 있다. 이것은 
이 모둘이 시험을 거치면 시험이 실패하였다는것을 의미한다. 반대로 모둘이 명세서에 
따라 동작하지 않으면 시험은 성공하게 된다. 작성된 모둘에 대하여 시험해 줄것을 부탁 
받은 프로그람작성자는 실패(부정확한 동작)가 뒤따라 일어 나는 그런 방법으로 모둘을 
실행시 킬것을 요구한다. 이것은 프로그람작성 자의 창조적 인 본능과 대 치된다. 

결 론은 불가피 하게 프로그람작성 자가 자기 가 작성한 모둘을 시 험하지 않도륵 하는것 
이 다. 프로그람작성 자가 모둘을 작성한 다음에 모둘에 대 한 시험은 창조자가 파괴적 인 
행동을 하도록 하고 그 창조물을 파괴하도록 할것을 요구한다. 실행 에 기초한 시험 이 그 
밖의 누군가에 의해서 진행 되 여 야 할 두번째 리유는 바로 프로그람작성 자가 설계 나 명세 
서의 일부 측면에 대 하여 잘못 리해 하고 있을수도 있다는것 이 다. 만일 시험 이 그밖의 누 
군가에 의하여 진행 되 면 그러한 오유는 발견될수도 있 다. 그럼 에 도 불구하고 오유검 사수 
정(실패의 원인을 찾고 그 오유를 정정한다.)은 그 코드에 제일 친숙한 사람인 원래의 프 
로그람작성 자에 의하여 제 일 잘 수행 될 수 있 다. 

프로그람작성 자가 자기의 코드를 시 험하지 말아야 한다는데 대 해서 는 더 이상 언 
급하지 않는다. 이제 프로그람작성과정을 고찰해 보자. 프로그람작성자는 처음에 모둘 
에 대한 상세설계를 읽는다. 즉이것은 흐름도표 또는 보다 좋기는 의사코드의 형식 
으로 될수도 있다. 그러나 어떤 기법을 리용하든지간에 모둘을 콤퓨터에 넣어 주기전 
에 철저 히 탁상검 열을 진행하여 야 한다. 즉 프로그람작성 자는 매 시 험실례 가 정 확히 
실행된다는것 을 검 사하기 위하여 상세설계를 추적하면서 여 러 가지 시험실례 로써 흐름 
도표나 가상코드들을 검사해야 한다. 상세설계가 정확하다고 할 때만 본문편집기가 호 
출되고 모둘이 코드작성될것이다. 
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일단 모둘이 기계가독형식으로 작성되면 그것은 일련의 시험을 거치게 된다. 우선 프 
로그람작성 자는 모둘를파일 을 시 도한다. 이것 이 성과적 으로 진행되 면 다음단계는 그것 들을 
련결하고 적재하는것이다. 그다음에는 모둘의 실행을 시도한다. 만일 모둘이 실행되면 모 
둘이 정확히 동작하는가를 결정하기 위하여 상세설계를 탁상검열할 때 리용한 시험실례와 
같은 시험실례가 리용된다. 그다음 만일 모둘이 정확한 시험실례가 리용될 때 정확히 실행 
되면 프로그람작성자는 모둘의 로마스트성을 시험하기 위하여 부정확한 자료에 의한 시험 
을 시도한다. 모둘이 정확히 동작하면 체계적인 시험이 시작된다. 이것이 바로 프로그람작 
성 자가 수행 하지 말아야 하는 체계적 인 시 험 testing ) 0 ] 

만일 프로그람작성자가 이러한 체계적인 시험을 진행하지 않는다면 과연 누가 그것 
을 진행 하는가? 6丄2에서 언급한바와 같이 SQA 그룹에 의해서 독립적 인 시험 이 진행되 여 
야 한다. 여 기 서 중요한것 은《 독립 적》이 라는 단어 이 다. SQA 그룹이 실 지 로 개 발림 과 
독립일 때 에만 SQA 그롭성원들은 그들의 작업을 저애할수 있는 제품최종기 한과 갈은 압 
력을 쏘프트웨 어제품개 발관리 자들로부터 받음이 없이 제품이 실지로 명세서를 만족시킨 
다는것 을 담보하기 위한 자기 들의 사명 을 수행할수 있 다. SQA 성 원들은 자기 들의 관리 자 
에게 보고해 야 하며 결국 자기들의 독립성을 지켜야 한다. 

그러면 체계적인 시험은 어떻게 진행하는가? 시험실례에서 하나의 본질적인 부분은 
시 험 이 실 행 되 기 전 에 기 대 되 는 출력 에 대 한 서 술이 다. 시 험 자가 말단에 앉아서 모둘을 
실행 시키 고 시 험실례 를 아무렇 게 나 넣어 주고 그다음에 화면을 보면서 《 내 추측에 는 옳 
은것 갈다.》라고 하는것 은 완전히 시 간랑비 로 된다. 또한 시 험 자가 시 험실례 를 매 우 세 
심하게 계 획 하고 매 개의 시 험실례를 차례 로 실행시키고 출력 을 지켜 보고 나서 〈〈옳소， 
확실히 정확해.》라고 하는것도 다같이 헛된 일이다. 만일 프로그람작성자가 자기들이 작 
성한 코드를 시 험하도록 하면 프로그람작성 자는 자기 들이 기 대하던것 을 보게 되는 위 험 
이 항상 존재한다. 그러한 위 험은 시험 이 그밖의 다른 사람에 의해서 실행될 때 에도 발 
생할수 있다. 그에 대한 해결책읏 관리자측이 시험을 진행하기전에 시험실례와 그에 대 
한 기대되는 결과자료를 다 기록해 두도록 하는것이다. 시험이 다 진행된 다음에 실제의 
결과자료를 기록해 두고 기대되는 결과자료와 비교한다. 

시 험 실 례 는 절 대 로 버 리 지 말아야 하기 때 문에 작은 기 업 체 와 제 품에 대 해 서 도 기 계 
가독형 식 으로 기 록해 두는것 이 중요하다. 그 리유는 바로 그것 이 유지 정 비 에서 필요하기 
때문이다. 제품이 유지정비되는 동안 회귀시험이 진행되여야 한다. 이미 제품이 정확히 
실행되 였다고 기 록된 시험실례들은 축적되 여 제품에 새 로운 기 능을 추가하기 위하여 만 
든 변경 이 제품의 현존기능을 파피 하지 않는다는것을 담보하기 위하여 재실행되 여 야 한 
다. 이에 대해서는 16장에서 더 구체적으로 고찰하도록 한다. 

6. 7. 언제 시험들 끝내는가 

제품이 몇년동안 성과적으로 유지정비된후에 그 유용성이 마침내 없어 질수 있으며 
전자관이 반도체소자로 교체된것처 럼 전혀 다른 제품으로 교체될수 있다. 달리 말하면 제 
품이 아직은 쓸모 있을수도 있지만 그것을 새로운 하드웨어에 이식하거나 그것을 새로운 
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조작체계에서 동작시키는데 드는 비용은 새로 제품을 개발하는 비용보다 더 클수 있다. 
그러므로 결국 쏘프트웨어제품은 폐기되여 더이상 봉사되지 않게 된다. 쏘프트웨어가 어 
쩔수 없이 버려 지게 될 그 시점에서만 시험이 중지되게 된다. 

이제는 필요한 배경자료를 모두 고찰하였으므로 객체들이 보다 자세히 고찰될수 있 
다. 이것은 다음장의 주제이다. 


요 약 

이 장의 중요한 화제는 시험이 쏘프트웨어개발공정의 모든 활동들과 병렬로 진행되 
여 야 한다는것 이 다. 이 장은 품질문제 에 대 한 서술로 시 작된다 (6.1). 다음에는 관통심사 
회 의 와 검 토에 대 한 주의 깊 은 론의 와 함께 비 실 행 에 기 초한 시 험 이 서 술된 다 (6.2). 그 
다음에는 실행에 기초한 시험이 서술되고 (6.3 과 6.4) 유용성，믿음성，로마스트성，성능 그 
리고 정확성을 비롯한 시 험해 야 할 제품의 동작특성 이 론의된다 (6.4.1 부터 6.4.5). 6.5 에 
서 정 확성증명 에 대 하여 소개 하고 이와 같은 증명의 실례를 6.5.1 에 주었다. 그다음 쏘 
프트웨어공학에 서 정 확성증명 의 역 할이 분석 된 다 (6.5.2 와 6.5.3). 또 하나의 중요한 론점 
은 체계적 인 실행 에 기초한 시험 이 프로그람작성 자가 아니 라 독립적 인 SQA 그룹에 의해 
서 진행되여야 한다는것이다 (6.6). 마지막으로 시험이 언제 중지되는가 하는것을 론의하 
였 다 (6.7) 


보 충 

시험과정에 대한 쏘프트웨어개발자들의 태도는 시험을 제품이 몇년동안 정확히 동작 
하는가를 고찰하기 위한 수단으로 보는 태도로부터 시험 이 요구사항확정과 명세작성, 설 
계 그리고 실현오유를 방지한다고 보는 현대적인 태도로 변화되였다. 이러한 전진에 대 
해서는 문헌 [Gelperin and Hetzel, 1988] 에서 서술하고 있다. 쏘프트웨어시험의 본성과 그 
것이 왜 그렇게 어려운것인가 하는 리유에 대해서는 문헌 [Whittaker, 2000] 에서 서술하고 
있 다. 

문헌 [ Tevonen , 1996] 을 비 롯하여 IEEE Software 1996년 1월 호에 는 쏘프트웨 어 의 품 
질과 관련한 기사들이 많이 게재되여 있다. IEEE Computer 1996년 11월호에도 쏘프트웨 
어 의 품질 에 대 한 기 사들이 들어 있 다. Communications of the ACM 1997 년 6 월 호에 도 역 
시 쏘프트웨어 의 품질 에 관한 일 련의 기 사들이 들어 있 다. 특별 히 흥미 를 끄는것 은 쏘프 
트웨 어개 발공정 을 개 선 하는것 이 쏘프트웨 어 품질 에 주는 영 향을 서 술한 문헌 [Herbsleb et 
al „ 199刀과 McDonnel - Douglas 에 서 쏘프트웨 어 의 품질 을 개 선하기 위 하여 전체 적 인 품질 
관리를 어떻게 리용하였는가에 대하여 서술한 문헌 [ Arthur , 199刀이다. 품질을 개선하기 
위 한 기 타 다른 방법 들은 문헌 [Onoma and Yamaura , 1995] 에 서 술되 여 있 다. 쏘프트웨 어 
제품의 전반적품질을 평 가하는 방법 은 문헌 [Boloix and Robillard , 1995] 에서 서 술하고 있 
다. 쏘프트웨어품질과 관련한 일화들은 문헌 [ Voas ，1999] 에 서술되여 있다. 믿음성은 
IEEE Software 1995년 5월호 기 사들에 서 술되 여 있 다. 
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문헌 [Baber, 198 刀에서 는 프로그람의 정확성 증명에 대하여 잘 소개하고 있 다. 정확성 
증명 의 표준기 술의 하나는 호아의 론리 라고 불리 우는것 을 리용하는것 인데 [Hoare, 1969] 에 
서 술되 여 있 다. 제 품이 명세서 를 만족시키 고 있 다는것 을 담보해 주는 또 다른 하나의 방 
법은 매 단계에서 정확성을 유지하는가를 검사하면서 제품을 계단식으로 개발하는것이다. 
이에 대해서는 문헌 [Dijkstra, 1969a, and, Wirth, 19 기]에 서술되여 있다. 쏘프트웨어공학집 
단에 서의 정 확성증명 과 관련 한 중요한 론문이 문헌 [DeMillo, Lipton, and Perlis, 1979] 에 
서 술되 여 있다. IEEE (Standard for Software Reviews) [IEEE 1028, 199 기은 비 실행 에 기 초 
한 시험 에 대 한 정보를 제공하는 중요한 문헌으로 되고 있다. 검 토를 진행하는 방법 이 
그것의 효과성과 함께 문헌 [Ackerman, Buchwald, and Lewski, 1989] 에 서술되 여 있 다. 대 
규모쏘프트웨 어제품 (25 만코드행)에 대 한 검토에 대해서는 문헌 [Russell, 1991] 에 서술되 여 
있다. 검토와 관련된 경험에 대한 정보자료들은 문헌 [Doolan, 1992, and Weller, 1993] 에 
들어 있 다. 림 의 규모를 줄이고 검 토를 위해서 기 다리 게 되 는 시 간을 최 소화하는것 과 같 
은 비 용에 관한 문제 는 문헌 [Volta, 1993] 에 서 술되 였 다. 대 규모쏘프트웨어 의 검 토를 진 
행 하는데 드는 비 용과 리득을 타산하는 실험 은 문헌 [Porter, Siy, Toman, and Votta, 1997] 
에 서술되 였다. 검 토와 관련 한 여 러 가지 유용한 론문들은 문헌 [Wheeler, Brykczynski, and 
Meeson, 1996] 에서 찾아 볼수 있다. 검 토령역 에서의 앞으로 가능한 연구개 발에 대 해서는 
문헌 [Johnson, 1998] 에 서 제 기하였 다. 

실행에 기초한 시험에 대한 고전적인 저서는 문헌 [ Myers , 1979] 이다. 이 저서는 시 
험분야에 큰 영 향을 주는 문헌 으로 되 고 있 다. 문헌 [ DeMiUo , Lipton , and Sayward , 1978] 
은 시 험자료의 선택 과 관련한 정 보들을 서 술한 훌륭한 문헌으로 되 고 있 다. 류사한 문헌 
[ Beizer , 199이은 시험에 대한 개론, 좋은 편람으로 되고 있 다. 이와 류사한 저서는 문헌 
[ Hetzel , 1988] 이다. 

특히 객체지 향파라다임 에 대 하여 보면 Communications of the ACM 1994 년 9 월호에 는 
객체지향쏘 프트웨 어의 시험과 관련한 수많은 기사들이 게재되여 있다. 문헌 [Kung, Hsia 
and Gao, 1998] 은 객체 지향시험 과 관련한 책 이며 문헌 [Sykes and McGregor, 200이도 마 
찬가지 이 다. 

IEEE Software 1989년 5월호에는 시험문제와 관련 한 폭넓은 기사들이 게재 되여 있 
다. 실행 및 비실행에 기초한 시험이 모두 포함되여 있다. 쏘프트웨어시험 및 분석과 관 
련한 국제 토론회회 보들에는 시 험 문제 와 관련하여 우와 류사하게 넓 은 범 위 에서 서 술하 
고 있 다. Communications of the ACM 1997 년 4 월 호에 서 는 오유수정 검 사에 대 하여 서 술 
하였다. 


문 제 

6.1. 용어 정 확성 증명 과 검 증, 타당성 이 이 책 에 서 는 어 떻 게 리 용되 고 있는가? 

6.2. 어느 한 쏘프트웨어개발기업체에는 쏘프트웨어의 검증과 타당성이 물론 개발 
을 진행하는 17명 의 관리 자를 비 롯한 83명 의 쏘프트웨어 전문가들에 게 있다. 최 근의 
통계 는 그들이 28%의 시 간을 검 증과 타당성증명 에 돌리 고 있 다는것 을 보여 주고 있 
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다. 어떤 관리자의 회사에 대한 년 평균비용은 14 만딸라이고 반면에 비관리성원인 전 
문가에 대해서는 년 평균 1 만 4 천딸라를 지출한다. 즉 우의 두 수자는 다 총적값을 
포함하고 있다. 비용 대 리득분석을 리용하여 기업체안에 SQA 그룹을 따로 두겠는가 
를 결 정하시 오. 

6.3. 두명의 관리성원을 포함하여 다만 7명의 전문가들로 구성된 회사에 대하여 련습 
문제 6.2 에서 제기한 비용 대 리득분석을 반복하시오. 기타 다른 수자들에 대해서는 달라 
진것이 없다고 가정하시오. 

6.4. 한개의 모둘을 11 일동안 시 험하여 두개의 오유를 발견하였 다. 이것은 기 타 다른 
오유들의 존재 에 대 하여 무엇을 말해 주는가? 

6.5. 관통심사회의와 검토사이의 류사한 점은 무엇이며 차이점은 무엇인가? 

6.6. 당신은 Ye Olde Fashioned Software 에 있는 SQA 그를의 한성원 이 다. 당신은 관리 
자에 게 검 토를 도입해 야 한다고 제 기하였 다. 그는 같은 코드부분에 대 하여 한 사람이 시 
험실례 를 실 행할수 있는 경 우에 오유를 찾기 위하여 4 명 의 사람이 시 간을 랑비 할 리유는 
없다고 대답했다. 당신은 무엇이라고 대답하겠는가? 

6.7. 당신들은 모두가 텍사스와 레네쎄에 모두 154 대의 지점을 가진 세금준비독점체 
인 텍 사스세 무소의 SQA 성 원들이다. 독점체 의 소유자들은 기 업전반에 서 리용할 새 로운 
형 태의 세 금준비쏘프트웨 어패 키지 를 구입하려 고 생각하고 있다. 그 쏘프트웨어 를 허 가하 
기전에 당신에게 그것을 철저히 시험할 임무가 맡겨 졌다. 이 쏘프트웨어의 어떤 특성들 
을 조사하겠는가? 

6.8. 텍 사스세 무소의 154 개 의 지 점 들은 모두 통신망으로 련결되 여 있다. 판매 대표는 
당신에게 자기 가 팔려 고 하는 통신쏘프트웨어 를 4 주동안 마음대 로 시험해 보도록 하였다. 
그 쏘프트웨어 에 대 하여 어떤 시험 을 진행하여 야 하며 왜 그런가를 설명 하시 오. 

6.9. 당신은 새로운 함선대 함선미싸일을 조종하기 위한 쏘프트웨어를 개발할 책 임을 
진 콜라몬트공화국의 해 군소장이다(문제 1.3). 쏘프트웨어 가 당신에 게 인수시 험 을 위하여 
배포되 였다. 쏘프트웨어 에 대 하여 어떤 특성을 시험해 야 하는가? 

6.10. 만일 순환불변량 

s = y [이 + y [ l ] + … + y [ k - l ] 

이 식 (6.4) 대 신 에 리용된 다고 하면 6.5.1 의 정 확성 증명 에 대 하여 어 떤 일 이 벌 어 지 게 되 
는가? 

6.11. 당신은 순환불변량에 대하여 얼마간의 경험을 가지고 있고 불변량 (6.4) 이 그림 
6-6 에 있는 순환에 대 한 정 확한 불변량이라는것 을 알고 있다고 가정 하자. 출력명세 서 (6.3) 
가 순환불변량에 대 하여 본질적 인 결과로 된다는것을 밝히시오. 

6.12. 다음의 코드토막을 고찰해 보시오. 
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k - 0; 

g 

while (k < n ) 

{ 

k = k + 1; 

g = g * k ; 

} 

만일 n 이 정 수이면 이 코드토막은 g = n ! 을 정 확히 계 산해 낸 다는것 을 증명하 
시오. 

6.13. 의 뢰 자에 게 배 포된 제 품이 실 지 로 의 뢰 자가 요구한것 이 아니 라고 하는 경 우에 
이 문제 에 대 하여 정 확성 검 사를 진행할수 있는가? 리 유를 밝히 시 오. 

6.14. 디지크스트라의 명령문 (6.3) 을 시험이 아니라 정확성증명에 리용하자면 어떻게 
변화시 켜 야 하는가? 6.5.2 의 실례연구를 명 심 하시 오. 

6.15. 교원이 지정한 언어 를 리용하여 나우르의 본문처 리 문제 (6.5.2) 에 대 한 해 결 방안 
을 설 계 하고 실 현 하시 오. 시 험자료에 대 하여 그것 을 실 행 하고 발견한 오유의 수와 매 
오유의 원인(실례로 론리적 인 오유, 순환곁수오유 등)을 기록하시오. 발견된 오유들을 모 
두 정 정하지 마시 오. 이 제 제 품들을 다른 학생 들과 교환하여 매 사람이 다른 제 품에 서 
발견한 오유들이 얼마나 되고 그것들은 새로운 오유인가 아닌가를 살펴 보시오. 그리 
고 오유들의 원인을 기록하고 찾은 오유류형를 서로 비교하시오. 부류별로 결과들을 표 
로 작성하시오. 

6.16. (과정안상 목표) 부록 1 에 있는 브로드렌즈지 역 아동병원쏘 프트웨 어제품에 대 
하여 유용성, 믿음성，로바스트성，성능, 정확성을 어떻게 시 험하겠는가에 대 하여 설명 
하시 오. 

6.17. (쏘프트웨 어 공학독본) 교원은 문헌 [ Whittaker , 2000] 의 복제 본을 배 포해 줄것 이 
다. 브룩스 (2.9) 는 쏘프트웨어 의 4가지 곤난이 본질 적 으로 어 렵 다고 생 각하고 있 다. 시 험 
이 본질적으로 어렵다고 또는 우연적으로 어렵다고 생각하는가? 
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제 7 장. 모듈로부터 객체에로 

일부 콤퓨터잡지 들은 객체 지향파라다임 이 1980년대 중엽 의 돌발적 이 고 극적 인 새 로 
운 발견이며 당시에 인기 있던 구조화파라다임에 대처한 혁신적인 선택이였다고 암시하 
였다. 그러나 사실은 그렇지 않다. 모둘성에 대한 리론은 1970년대와 1980년대에 끊임 없 
는 발전을 이 룩하였으며 객체는 모둘성리론의 테 두리안에서의 단순한 론리적 인 발전이였 
다(다음의 《 알고 싶은 문제 ) 를 보시 오.). 


알:2 싶 e ©제 

객 체지 향개 념 들은 모.의 언어 Simula 67 [Dahl and Nygaard, 1966] 로 1966 년에 4 대 되 였 
다. 그러나 그때는 그 기능이 실용화되기에는 너무 일렀다. 그래서 1980년대 초까; 그것 
은 표현화되지 않았다. 1980년대 초에 그것은 본질상 모듈성리론의 범위안에서 재 y •명되 
였 다. 

이 장의 다른 실례들은 세계가 선진기술을 리용할수 있도록 준비될 때까지 立 기술이 
활성화되지 않는 방식이 존재한다는것을 말해 주고 있다. 실례로 정보은페 (7.6) 는 .9 기년 
에 파나스에 의 하여 쏘프트웨 어의 범위 내 에서 처 음으로 제 기되 였다 [Pamas, 1971]. IL 러 나 
그 기 술은 약 10년후 즉 교갑화와 추상자료형 들이 쏘프트웨 어공학의 부분으로 되 ᅵ 을 때 
까지는 널리 일반화되지 못하였다. 인간은 반드시 새로운 착상이 처음 나왔을 때기 아니 
라 그것들을 리용할 준비 가 되 여 있을 때 에만 받아 들이는것 같다. 


이 장에서는 모둘성의 범위내에서 객체를 서술하였다. 객체지향파라다임이 구조화파 
라다임보다 왜 더 우월한가를 리해하지 못하고서는 객체를 정확히 리용하는것이 매우어 
렵기때문에 이러한 방법을 취하였다. 그리고 이것을 위해서는 객체가 다만 모둘의 개념 
으로부터 시 작되 고 지 식의 체 계안에서 모둘의 다음단계 로 된다는것 을 정 확히 리해하는것 
이 필요하다. 


7. 1 . 모듈이란 무엇인가 

큰 제품이 하나의 유일한 코드블로크로 이루어 져 있을 때 유지정비는 상상할수 없 
을 정도로 어렵다. 이런것을 만든 사람에게 있어서도 코드를 오유수정하기 위하여 노력 
한다는것은 대 단히 어 려운 일이 다. 또 다른 프로그람작성자가 그것을 리해한다는것은 사 
실상 불가능하다. 해결책은 그 제품을 모둘이라고 부르는 보다 작은 쏘각들로 분할하는 
것이다. 모둘이란 무엇인가? 제품을 모둘로 분할하는 방식 그자체가 중요한가 아니면 큰 
제품을 보다 작은 코드조각으로 분할하는것 이 중요한가? 

일 찌 기 스리 본스 ( Stevens ), 마이 어 스 ( Myers ) 와 콘스탄린 ( Constantine ) 이 이 와 같은 모 
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둘에 대하여 설명하려고 시도하였다. 그들은 모둘은《체계의 다른 부분들이 그것을 불러 
낼수 있는 이름을 가지며 더 좋기는 자기의 고유하고 명백한 변수이름들의 모임을 가지 
는 한개 또는 그이 상의 련관된 프로그람명 령 들의 모임》이 라고 정 의 하였 다 [Stevens, 
Myers, and Constantine, 1974]. 다른 말로 모둘은 처 리절차，함수，방법 을 호출하는 방식으 
로 호출할수 있는 한개의 간단한 코드블로크들로 이 루어 져 있다. 이 러 한 정의는 극히 
일반적인것 갈다. 그것은 내부적이든 개별적이든 콤파일되는 모든 종류의 처리절차와 함 
수들을 포함하고 있다. 그것 은 비 록 자기 의 고유한 변 수들을 가질수 없 다고 해 도 
COBOL 단락들과 부분들을 포함하고 있다. 왜 냐하면 이 정의는 변수이름들의 명백한 모 
임 을 가지 고 있 다는 특성 이 선택 적 이라는것 을 말해 주고 있기때 문이 다. 그것 은 또한 다 
른 모둘들에 삽입되는 모둘들을 포함하고 있다. 그러나 이 정의는 일반적이기는 하지만 
그리 완전한것 은 아니 다. 실례 로 아쎔 블리 어마크로는 불러 내 지 못하며 따라서 그것 은 
앞의 정의에 따르면 모둘이 아니다. 

C 언어와 C++ 언어에서는 류사하게 제품안에 include 로 정의된 선언들의 머리부파일 
들은 불러 내지 못한다. 즉 Ada 패키지(추상자료형의 실현)라든가 Ada 일반명(마크로)도 불 
러 내지 못한다. 한마디로 이 정의는 너무 제한적이다. 

요르돈 (Yourdon) 과 콘스탄린 (Constentine) 은 보다 일반적인 정의를 주었다. 즉《모둘 
은 말그대로 경계요소에 의하여 제한되고 집합식별자를 가지고 있으며 어휘상 린접되여 
있는 프로그람명 령 문들의 렬 이 다.》 [Yourdon and Constantine, 1979]. 경 계요소의 실례 로 
서 Pascal 이나 Ada 와 같은 블로크구조화된 언어들에서의 begin … end 쌍파 C++ 혹은 Java 
언어들에서의 M 쌍을 들수 있다. 이 정의는 앞선 정의에서 제기된 모든 경우들을 포함 
할뿐아니 라 포괄범 위 가 매 우 넓으므로 이 책 의 전반에 서 리용되 고 있 다. 특히 고전적 인 
파라다임 에서의 처 리 절차와 함수들은 모둘이 다. 객체지향파라다임 에서 객체 는 모둘이 고 
객 체안에 서 의 방법 도 역 시 모둘이 다. 

모둘화의 중요성을 리해 하기 위하여 어 느 정도 공상적 인 다음의 실례들을 고찰하자. 
죤 헨 스 (John Hence) 는 아주 무능한 콤퓨터 설 계 가였 다. 그는 아직 도 NAND 문회 로와 NOR 
문회 로가 완비성 을 가진 다는것 즉 모든 회 로들을 NAND 문회 로나 NOR 문희 로만 가지 고 
도 만들수 있다는것 을 발견하지 못했다. 따라서 죤은 AND , OR 그리 고 NOT 문회 로를 리 
용하여 산수론리장치 와 밀 기등록기， 16 개 의 등록기 를 만들기 로 결 심하였 다. 그 결 과로서 
만들어 진 콤퓨터를 그림 7-1 에 보여 주었다. 여 기서는 세개의 구성요소들이 단순한 방 
식으로 서로 련결되여 있다. 한 설계가는 세개의 규소소편으로 회로를 만들어야 한다고 
결심하고 그림 7-2 에 보여 준바와 같이 세개의 소편들로 설계를 진행하였다. 한개의 소 
편은 산수론리장치의 모든 문회로들을 가지고 있고 두번째 소편에는 밀기등록기가 들어 
있으며 세번째 소편은 등록기 를 위한것 이 다. 이 시 점 에서 존은 술집 에 서 누군가가 자기 
에게 오직 한가지 종류의 문회 로로 된 소편들을 만드는것 이 가장 좋다고 말한것 이 어 렴 
풋이 생 각나서 소편들을 다시 설 계하였 다. 그는 소편 1에 는 모두 AND 문회 로들을 넣 고 
소편 2 에는 모두 OR 문희로들을 넣었으며 소편 3 에는 모두 NOT 문회로를 넣도록 하였다. 

그 결과물을 그림 7-3 에 도식적으로 보여 주었다. 

그림 7-2 와 7-3 은 기능상 같다. 즉 정 확히 말하여 그것들은 꼭 같은 일을 한다. 그 
러나 이 설계들은 뚜렷한 서로 다른 특성을 가지고 있다. 
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’-3 은 그림 7-2 보다 대 단히 리해 하기 어 렵 다. 수자론리 
농들은 인차 그림 7-2 에 있는 소편들이 산수론리장치 , % 
!한다는것 을 알게 될 것 이 다. 그러 나 하드웨 어 전문가들 
AND , OR , NOT 문희 로의 기 능을 리 해 하기 힘 들것 이 t 
-3 에 있는 회 로들에 대 한 교정유지 정 비 는 오유를 범하: 
卜가를 결 정하는것 이 어 려울것 이 다. 다른 한편 그림 7-2 
있 다면 그 결 함이 산수론리장치 가 동작하는 방식 , 밀^ 
록기가 동작하는 방식에 있겠는가를 결정함으로써 그 
와 류사하게 만일 그림 7-2 의 콤퓨터가 파괴된다면 어 
는것 은 상대 적 으로 쉽다. 그리 고 만일 그림 7-3 에 있는 
I 소편들을 모두 교체하는것 이 좋을것 이 다. 









그림 7-3. 세개의 소편으로 조립한 그림 7-1 의 를퓨터 


셋째 로, 그림 7-3 의 콤퓨터 는 확장 또는 보강하기 가 힘 들다. 만일 새형의 산수론리장 
치 가 필요된다든가 혹은 보다 빠른 등록기 들이 요구된다면 처 음부터 다시 설계하여 야 한 
다. 그러 나 그림 7-2 의 콤퓨터의 설계는 적절한 소편을 쉽 게 교체할수 있게 한다. 아마도 
가장 나쁜 점 은 그림 7-3 의 소편들이 임의의 새 로운 제품들에서 다시 리용될수 없다는것 
이 다. AND , OR , NOT 문회 로들의 특정 한 조합은 그것 들이 설계 된 제 품이 외 의 다른 임 의 
의 제 품들에 서 리용될 수 있 다고는 말할수 없 다. 모든 가능성 으로 보아 그림 7-2 의 세 가 
지 소편들은 산수론리장치 , 밀 기등록기 또는 등록기 들을 요구하는 다른 제 품들에 서 다시 
리용할수 있 다. 

여기서 문제점은 쏘프트웨어제품들이 그림 7-2 에서처럼 개별적소편안에서는 최대한 
의 관계를 가지고 소편들사이에서는 최소한의 관계를 가지도록 설계되여야 한다는것이다. 
모둘은 그것 이 한가지 동작 혹은 련속적 인 동작들을 수행하는 다른 모둘들과 련결되 여 
있다는 점 에서 소편들에 비 유할수 있다. 전체적 인 제 품의 기 능은 고정되 여 있다. 결정 해 
야 할것은 제품을 어떻게 모둘로 분할하는가 하는것 이 다. 1장에서 지적한것처 럼 합성/구 
조화된 설 계 [Stevens, Myers, and Constantine, 1974] 는 유지 정 비 비 용과 전 체 쏘프트웨 어 예 
산의 주요한 구성 요소들을 줄이 기 위한 방도로서 제 품을 모둘들로 분할하기 위한 론리 적 
인 근거를 준다. 유지정비의 노력은 점점 그것이 정정이든, 완성이든, 적응이든 개별적 
모둘안에서 는 최 대 한도의 호상작용이，모둘들사이 에서 는 최 소한도의 호상작용이 있을 
때 줄어 들게 된 다. 달리 말하여 합성/구조화된 설 계 (C/SD) 의 목적 은 제 품의 모둘분해 가 
그림 7-3 이 아니 라 그림 7-2 를 조립한다는것 을 담보하는것 이 다. 마이 어 스는 모둘안에 서 
의 호상작용정도를 나타내는 모둘의 응집도와 두 모둘사이의 호상작용정도를 
나타내는 모둘의 결합도에 대한 착상을 하였다 [Myers, 1978b], 더 정확히 말하면 
마이 어 스는 응집 도가 아니 라 강도 Cs / reng / A ) 라는 용어 를 리 용하였 다. 그러 나 응집 도이 라는 
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용어가 용어 강도보다 더 낫다. 왜냐하면 모둘이 고강도 또는 저강도를 가질수 있고 또 
저강도라는 표현에 무엇인가 선천적인 모순 즉 무엇인가 강하지 못하면 약하다고 하는 
모순이 있기때문이다. 일부 저자들은 결합이라는 표현대신에 속박이라는 표현을 리용하 
고 있다. 유감스럽게도 속박은 어떤 값들이 변수들에 속박된다는것과 같이 콤퓨터과학의 
다른 분야에서도 리용되고 있다. 그러나 결합은 이런 함축된 의미를 가지고 있지 않으며 
따라서 속박보다 더 낫다. 

이 점에서 모둘의 작용, 모둘의 론리，모둘의 문맥을 서로 구별하는것이 필요하다. 
모둘의 작용 ( acft ' o «) 은 그것이 무엇을 하는가 하는 거동 ( fteAaWor ) 이다. 실례로 모둘 m 의 
작용이 자기 인수들의 2차뿌리 를 계 산하는것 을 들수 있다. 모둘의 론리 ( fog 쒸는 모둘이 
자기의 작용을 어떻게 수행하는가 하는것이다. 즉 모둘 m 의 경우에 2차뿌리를 계산하는 
특정한 방법은 뉴톤의 방법이다 [Gerald and Wheatley , 1999]. 모둘의 문맥 ( contec /) 은 그 
모둘의 특정한 리용 ( wage ) 이 다. 실례 로 모둘 이은 배 정확도옹근수의 2차뿌리 를 계 산하기 
위하여 리용된다고 하자. C / SD 에서의 중요한 점은 어 떤 모둘에 할당된 이 름은 그 모둘의 
작용이며 그것의 론리나 그것의 문맥으로 되지 않는다는것이다. 그렇기때문에 C / SD 에서 
모둘 m 은 compute square root (2 차뿌리를 계산하시오.)라고 이름 지어야 하며 이 모둘의 
론리와 문맥은 이름의 견지에서 보면 상관이 없다. 

7. 2. 응 집 도 

마이 어 스는 응집 도를 7개 의 범 주 혹은 준위 로 정 의하였 다 [ Myers , 1978 b ], 현대 콤퓨터 
과학의 견지 에 서 볼 때 마이 어스의 첫 두개 준위 들을 완전히 갈은것 으로 간주된 다. 보다 
정확하게는 앞으로 보게 되는바와 같이 기능적 인 응집도는 구조화파라다임에 대하여 최 
량적 이며 반면에 정 보적인 응집도는 객체지향파라다임 에 대 하여 최 량적 이 다. 


7. 

j ■정보적 인 

응집도 

(좋다.) 


1 기능적인 

응집도 


5. 

통신적 인 

응집도 


4. 

절 차적 인 

응집도 


3. 

림 시적인 

응집도 


2. 

론리 적인 

응집도 


1 . 

일치적인 응집도 

(나쁘다.) 


그림 7-4. 응집도의 준위 

결과적인 순서배렬을 그림 7-4 에 보여 주었다. 이것은 임의의 정렬에 대한 선형적인 
등급이 아니다. 그것은 단지 상대적인 순서배렬 즉 어느 형식의 응집도가 높고(좋고) 어 
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느 형식의 응집도가 낮은가(나쁜가) 하는것을 결정하기 위한 한가지 방법인것이다. 

무엇 이 높은 응집도를 가진 모둘을 이루는가 하는것을 리해 하자면 다른 끝에서 시 작 
하여 보다 낮은 응집도준위들을 고찰하는것이 필요하다. 

7. 2. 1 . 일치적인 응집도 

모둘은 만일 그것이 전혀 관련이 없는 여러가지 작용들을 수행한다면 일치적인 
응집도를 가진다. 일치적인 응집도를 가진 모둘의 실례는 다음행을 인쇄한다든가 두 
번째 인수를 구성하는 문자들의 렬을 반대 로 놓는다든가 5번째 인수에 7을 더한다든 
가，4번째 인수를 류동소수점수로 변환한다든가 등이다. 한가지 명백한 질문은 이러 
한 모둘들이 실천적으로 어떻게 제기될수 있겠는가 하는것이다. 가장 보편적인 리유 
는 《모든 모듈들은 35~50개의 실행가능한 명령문들로 이루어 진다.》 와 갈은 규칙 을 
엄격 히 실시한 결과에 있다. 만일 쏘프트웨어 기업체 가 모둘이 너무 크거 나 너무 작지 
말아야 한다고 주장하면 두개 의 바라지 않은 일 들이 발생할것 이 다. 첫째 로, 두개 또 
는 그이상의 다른 리상적인 보다 작은 모둘들이 일치적인 응집도를 가진 보다 큰 모 
둘을 만들기 위하여 하나의 덩어리로 합쳐 져야 한다. 둘째로, 관리하기에는 너무 
크다고 생각되는 잘 설계된 모둘들에서 떼낸 일부 조각들이 다시 일치적인 응집도를 
가진 모둘들로 된다. 

일치적인 응집도가 그토록 나쁜 리유는 무엇인가? 일치적인 응집도를 가진 모둘들 
은 두가지 심중한 결함을 가지고 있다. 첫째로，그러한 모둘들은 교정유지정비와 확장과 
같은 제품의 유지정비성을 떨어 뜨린다. 제품을 파악하려고 하는 견지에서 보면 일치적 
인 응집 도를 가진 모둘화는 모둘화가 전혀 되 여 있지 않은것 보다 더 나쁘다 [Shneiderman 
and Mayer , 1975]. 둘째로, 이러한 모둘들은 재리 용성이 없다. 이 절의 첫 번째 단락에서 
말한 일치적인 응집도를 가진 모둘은 임의의 다른 제품에서 전혀 다시 리용될수 있을것 
갈지 않다. 

재 리용성 의 결핍 은 심 중한 결 함이 다. 쏘프트웨어 를 만드는데 드는 비 용이 너 무 크기 
때 문에 모둘을 가능한 모든 곳에 서 다시 리 용하기 위 하여 노력 하는것 이 필 수적 이 다. 어 
떤 모둘을 설계 , 코드작성 , 문서 작성하며 더우기 시 험하는것 은 시 간이 많이 들고 따라서 
비용이 많이 드는 공정이다. 만일 잘 설 계 되 고 철 저 히 시 험 되 고 적당히 문서작성이 되 여 
있는 현존모둘이 또 다른 제 품에 서 리용될 수 있 다면 관리 자측은 현존모둘이 재 리용된 다 
고 주장할것이다. 그러나 일치적인 응집도를 가진 모둘이 재리용될수 있는 방도가 전혀 
없으면 그것 을 개 발하는데 소비 된 비 용은 절대 로 보상될수 없 다(재 리용문제 는 8장에 서 
상세 히 론의한다.). 

일반적으로 일치적인 응집도를 가진 모둘을 수정하는것은 쉽다. 왜냐하면 그것이 여 
러 작용을 수행 하고 매 개가 한가지 작용을 수행하는 보다 작은 모둘들로 쪼개지기 때문 
이다. 
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7. 2. 2. 론리적인 응집도 

모둘은 그중 어느 하나가 호출하는 모둘에 의하여 선택되는 련관된 작용들을 련속 
수행할 때 론리적 인 응집도를 가지게 된다. 다음의 실례들은 모두 론리적 인 응집도를 가 
진 모둘의 실례로 된다. 

실례 1 다음파 같이 호출되는 모둘 new operation: 
function code = 7; 

new operation (function code, dummy 1, dummy 2, dummy 3); 

// dummy 1, dummy 2, dummy 3 은 dummy 변 수들 이 다. 

// 만일 function code 가 7 과 같으면 리 용되 지 않는다. 

이 실례 에서 new operation 은 네 개의 인수들로 호출된다. 그러 나 설명 문에서 언급된 
것처럼 만일 function code 가 7 과 같다면 그것들중 세 개는 필요 없다. 이것은 그것이 정정 
이든 확장이든 유지정비에 대한 일반적인 의미에서 가독성을 떨어 뜨린다. 

실례 2 모든 입출력을 실행 하는 객체 

실례 3 기본파일기록들에 대한 삽입，삭제，수정과 갈은 편집기능을 수행하는 모둘 

실례 4 0S"S2 의 초기 의 판본에 있는 론리 적 인 응집도를 가진 모둘은 13 개 의 각이 
한 작용을 수행하였 다. 그것 의 대 면부에 는 21 개 의 자료토막들이 들어 있 다 [Myers, 1978b], 

모둘이 론리적 인 응집도를 가질 때 두가지 문제 가 생 긴다. 첫째 로, 대 면부를 리 해 하 
기 힘 들다. 실 례 1이 바로 그 경 우에 해 당된다. 전체 적 인 모둘에 대 한 리해가능성 은 그로 
인하여 영향을 받을수 있다. 둘째로, 한가지이상의 작용에 대한 코드는 한데 얽히여 엄중 
한 유지정 비 문제 들을 산생 시킨다. 실례 로 입 출력 을 모두 진행하는 모둘은 그림 7-5 에서 
보여 준것처럼 구조화될수 있다. 만일 새로운 테프장치가 설치되면 1, 2, 3, 4, 6, 9, m 이 
라고 번호를 불인 부분들을 수정하는것이 필요할수도 있다. 이러한 변경들은 레이자인쇄 
기 가 1 과 3 부분들에 대 한 변경 의 영 향을 받기 때 문에 레이 자인쇄 기출력 과 같은 다른 형 태 
의 입 출력 에 부정 적 인 영 향을 줄수 있 다. 한데 얽 혀 있는 특성 은 론리적 인 응집도를 가 
진 모둘들에 서 특징 적 이 다. 이 특성 은 다른 제 품들에 서 그러한 모둘을 재 리용하는것 이 
어 렵 다는 결과를 초래한다. 


7. 2. 3. 림시적인 응집도 

모둘은 련관된 일련의 작용들을 제때에 수행할 때 림시적인 응집도를 가진다. 림시 
적인 응집도를 가진 모둘의 한가지 실례는 낡은 기본파일열기와 새로운 기본파일열기, 트 

랜잭션파일열기 그리고 파일인쇄, 판매지역표초기하, 첫 트랜잭션기록읽기와 첫 낡은 기본파 

일기록읽기로 명명한 모둘이 다. C/SD 가 나오기전에는 그러한 모둘을 초기 화실행 이라고 
불렀 을것 이 다. 

이 모둘의 작용들은 서로 약하게 련관되여 있지만 다른 모둘들의 작용들과는 더 강 
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하게 련관되여 있다. 실례로 판매지역표를 고찰해 보자. 그것은 이 모둘안에서 초기화되 
지만 판매지역표갱신과 판매지역표인쇄와 갈은 작용은 다른 모둘들에 위치하고 있다. 따 
라서 만일 판매지역표의 구조가 변하게 되면 아마 그 기업체가 이전에 기업활동을 진행 
하지 못한 나라의 지역들로 활동을 확대하고 있기때문에 수많은 모둘들이 변하게 될것이 
다. 회귀 오유(명백 히 제품과 련관되 여 있지 않은 부분에 생긴 변화로 하여 초래된 결함) 
가 보다 많이 생길 기회가 있을뿐아니라 만일 영향을 받은 모둘의 수가 크다면 한개 또 
는 두개의 모둘들이 무시되 기 좋은 기회 가 있다. 7.2.7 에서 설명한것 처 럼 판매지역표에 대 
하여 진행 되 는 모든 조작들을 한개 의 모둘안에 포함시키 는것 이 훨씬 더 좋다. 이 조작들 
每 필요할 때 다른 모둘들에 의하여 호출될수 있다. 이밖에 림시적인 응집도를 가진 모 
둘은 서 로 다른 제 품에 서 재 리 용될 수 없 을것 이 다. 


1. 모든 입력과 출력을 위한 코드 

2. 

입력만을 위한 코드 

3. 

출력만을 위한 코드 

4. 

디스크와 테 프 VO 를 위 한 코드 

5. 디스크 I / O 를 위한 코드 

6. 

데 프 I / O 를 위 한 코드 

7. 디스크입력을 위한 코드 

8. 

디스크출력을 위한 코드 

9. 

테프입 력을 위한 코드 

10. 

테프출력을 위한 코드 

1 : ； ： 1 

즈 一 

건반입력을 위한 코드 


그림 7-5. 모든 입력과 출력을 실현하는 모듈 


7. 2. 4. 절차적인 응집도 

모둘은 만일 그것이 제품이 따르는 일련의 단계렬들에 의하여 관계되는 일련의 작용 
들을 수행 한다면 절차적 인 응집도를 가지게 된다. 절차적 인 응집도를 가지고 있는 모둘 
의 실례는 자료기지로부터 부분번호의 읽기와 유지정비파일상에서 수정기록의 갱신이 다. 

이것은 명백히 림시적인 응집도보다 더 좋다. 즉 적어도 작용들은 절차적으로 호상 
련관되여 있다. 그렇다고 해도 동작들은 여전히 약하게 련관되여 있으며 또한 이 모둘은 
다른 제품에서 재리용될것 갈지 않다. 해결책은 절차적인 응집도를 가진 모둘을 독립적 
인 모둘들로 분해하여 매개 모둘이 한가지 작용을 수행하도록 하는것 이다. 
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7. 2. 5. 통신적인 응집도 

모둘은 만일 그것이 제품이 따르는 단계렬들에 의하여 관련되는 일련의 작용을 수행 
하고 모든 작용들이 동일한 자료상에서 수행된다면 통신적 인 응집도를 가지게 된다. 통 
신적인 응집도를 가진 모둘의 두가지 실례로서 자료기지에 있는 기록을 갱신하고 그것을 
검사흔적에 쓰기, 새로운 자리길을 계산하고 그것을 인쇄기에 보내기를 들수 있다. 이것은 
모둘의 작용들이 보다 밀접하게 련관되여 있기때문에 절차적인 응집도보다는 더 좋다. 
그러나 그것은 여전히 일치적인 응집도, 론리적인 응집도, 림시적인 응집도 그리고 절차 
적 인 응집 도와 똑 갈은 결 함을 가지 고 있다. 즉 모둘이 재 리 용될수 없 다는것 이 다. 그 해 
결책은 그러한 모둘을 독립적 인 모둘들로 분해하여 매개 모둘들이 한가지 작용을 수행하 
도록 하는것 이 다. 

겸사해서 베리 ( Ben 功가 림시적인 응집도，절차적인 응집도, 통신적인 응집도에 대하 
여 언급하면서 흐름도응집도 {/7 owctert co 뇨선 on ) 라는 용어를 사용하고 있는것은 흥미 있다. 
왜 냐하면 그러한 모둘들에 의하여 수행 되 는 작용들이 제 품흐름도에 서 린접해 있기 때 문이 
다 [ Beny ，1978]. 림시적인 응집도의 경우에 작용들은 그것들이 동시에 수행되기때문에 린 
접해 있게 된 다. 그것 들은 절 차적 인 응집 도에서 는 알고리 듬이 련속적 으로 수행 될 작용들 
을 요구하기 때 문에 린접해 있게 된 다. 통신적 인 응집 도에 서 도 그것 들을 련속적 으로 수행 
되는것외에도 작용들이 똑갈은 자료에 대하여 수행되기때문에 린접해 있게 된다. 따라서 
이러한 작용들이 흐름도에서 린접해 있게 되는것은 응당하다. 

7. 2. 6. 기능적인 응집도 

하나의 동작을 정 확히 수행 하든가 혹은 단일한 목적을 실현하는 모둘은 기능적 인 응 
집도를 가진다. 이와 갈은 모둘의 실례에는 용광로의 온도를 잰다; 전자의 자리길을 계산한 
다; 디스크에 쓴다; 판매수수료를 계산한다가 있다. 

기능적 인 응집도를 가진 모둘은 그 모둘이 수행하는 하나의 작용이 다른 제품들에서 
수행될 필요가 있기때문에 흔히 재리용될수 있다. 정확히 설계되고 철저히 시험되였으며 
문서화가 잘된 기능적인 응집도를 가진 모둘은 임의의 쏘프트웨어기업체들에 있어서도 
(경 제 적 으로, 기 술적 으로) 가치 가 있는것 이 며 될 수록 자주 재 리용되 게 된 다 (7.5). 

유지정 비는 기 능적 인 응집도를 가진 모둘상에서 수행 하기 가 더 쉽다. 첫째 로 기 능적 
인 응집 도는 오유를 고립시 킨다. 만일 용광로의 온도가 정 확히 읽 어 지 지 않는다는것 이 
사실이 라면 오유는 거의나 확정적 으로 모둘 용광로의 온도를 잰다에 있게 된다. 류사하게 
만일 전자의 자리길이 부정확하게 계산된다면 처 음으로 주시해 야 할것 은 전자의 자리길을 
계산한다라는 모둘이다. 

일 단 오유가 단일 한 모둘로 국부화되 면 다음단계 는 요구되 는 변경 을 진행하는것 이 다. 
기 능적 인 응집 도를 가진 모둘이 오직 하나의 작용을 수행하면 그러한 모둘은 일 반적 으로 
보다 높은 응집도를 가진 모둘보다 리해하기가 더 쉽다. 이렇게 리해하기 쉬운것은 또 
한 유지정비를 간단하게 해준다. 마지막으로 변경이 진행될 때 특히 모둘들사이의 결합 
도가 작게 되면 변경이 다른 모둘들에 영향을 줄 기회는 적어 지게 된다 (7.3). 
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기능적인 응집도는 또한 제품이 확장될 때 가치가 있다. 실례로 개인용콤퓨터가 
10 Mb 의 하드구동기를 가지고 있는데 제작자는 이제 대신에 30 Mb 의 하드구동기를 가진 
보다 강력한 를퓨터 의 모형 을 시 장에 내가려 고 한다고 하자. 모둘의 목록을 읽 고 나서 
유지정 비프로그람작성 자는 하드구동기에 쓴다라는 모둘을 찾는다. 명백 히 하여 야 할것은 
그 모둘을 더 큰 하드구동기에 쓴다라고 하는 새 로운 모둘로 교체하는것 이 다. 

겸사해서 다음과 같은 사실을 지적할 필요가 있다. 그림 7-2 에 있는 세개의 모둘들은 
기 능적 인 응집도를 가지 며 그림 7-3 의 설계 보다 그림 7-2 의 설계 가 더 좋다는데 대 하여 
7.1 에서 진행한 론증들은 정 확히 기 능적 인 응집 도가 더 좋다고 하는 앞의 론증과 같다. 

7. 2. 7. 정보적인 응집도 

모둘은 매개가 자기의 입력점을 가지고 있고 매 작용에 해당한 독자적인 코드가 있 
으며 모두 갈은 자료구조에 기초하여 수행되는 수많은 동작들을 수행한다면 그것은 정보 
적 인 응집도를 가지게 된다. 그 실례를 그림 7-6 에서 보여 주고 있다. 이것은 구조화된 
프로그람작성법에 어긋나지 않는다. 즉 매개 코드토막은 정확히 하나의 입력점과 하나의 
출력점 을 가지 고 있 다. 론리 적 인 응집도와 정 보적인 응집 도사이 의 주되 는 차이 는 론리 적 
인 응집도를 가진 모둘의 여 러 가지 동작들이 한데 얽 혀 있 다면 정 보적인 응집도를 가진 
모둘에서 는 매 개 동작의 코드가 완전히 독립 적 이라는것 이 다. 



랄뢰 

탈퇴 

랄뢰 


그림 7-6. 정 보적인 응집 도를 가진 모듈 

정 보적인 응집 도를 가진 모둘은 7.5 에서 설명한것 처 럼 본질상 추상자료형 의 실현이 며 
추상자료형 을 리 용할 때의 모든 우월성 은 정 보적인 응집 도를 가진 모둘이 리 용될 때 얻 어 
진다. 객체가 본질상 추상자료형 (7.7) 의 실례이기때문에 객체도 역시 정보적인 응집도를 
가진 모둘이 다. 그러므로 7.2 에서 는 정 보적 인 응집도가 객체지향파라다임지에 대 한 최 량화 


4) «1 단락에서 론의는 추상자료형이나 객체가 잘 설계된것을 전제로 하고 있다. 만일 
대상의 방법이 전혀 관련이 없는 동작을 수행하게 된다면 객체는 일치적인 응집도를 가전다. 
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이라고 지적하였다. 


7. 2. 8. 응집도의 실례 

응집도에 대 하여 좀 더 심도 있게 고찰하기 위하여 그림 7-7 에 있는 실례를 고찰해 
보자. 특히 두개 의 모둘을 설명할 필요가 있다. 합을 초기화하고 파일열기와 파일들을 담 
고 평균온도를 인쇄라는 모둘들이 모두 림 시 적 인 응집 도가 아니 라 일 치 적 인 응집도를 가 
진다고 명시되여 있다는 사실은 어느 정도 놀라울수 있다. 우선 모둘합을 초기화하고 파 
일열기를 생각해 보자. 


기능적 



그림 7-7. 매개 모듈의 응집을 보여 주는 모듈호상접속도 

그것 은 두 작용들이 임의의 계 산들을 수행 하기전에 수행 되 여 야 한다는 점 에서 제때 
에 관련되는 그 두개의 작용들을 수행한다. 따라서 모둘이 림시적 인 응집도를 가지 고 있 
는것처럼 보인다. 비록 합을 초기화하고 파일열기의 두 작용이 정말로 계산의 초기에 수 
행된다고 해도 또 다른 요인이 포함된다. 합을 초기화하는것은 문제와 관련이 있지만 파 
일열기는 문제 그자체와는 아무런 관련이 없는 하드웨어적인 문제이다. 두개 혹은 그이 
상의 서로 다른 준위의 응집도들이 하나의 모둘에 할당할수 있을 때의 규칙은 가장 낮은 
가능한 준위를 할당하는것이다. 따라서 합을 초기화하고 파일열기가 림시적인 응집도이든 
가 일치적인 응집도를 가질수 있기때문에 두 준위의 응집도들중 보다 더 낮은 일치적인 
응집도가 그 모둘에 할당되게 된다. 이것은 또한 파일들을 닫고 평균온도를 인쇄가 일치적 
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인 응집도를 가지게 되는 리유로 된다. 


7. 3. 결 합 도 

응집도가 어떤 모둘내에서의 호상작용의 정도라는것을 상기해 보자. 결합도는 두 
모둘사이의 호상작용의 정도이다. 응집도는 그림 7-8 에서 보여 주는바와 같이 여러가 
지 준위 들로 구분할수 있다. 좋은 결 합을 강조하기 위하여 여 러 가지 준위 들을 가장 
나쁜것부터 가장 좋은것의 순서로 설명하기로 한다. 


5 . 

자료결합(좋다) 

4. 

스탬프결합 

3. 

조종결합 

2. 

공통결합 

1 . 

내용결합(나쁘다) 

그림 7-8. 결합의 준위 


7. 3. 1. 내용결합 

두 모둘은 만일 한개의 모둘이 다른 모둘의 내용들을 직접적으로 참고한다면 내용상 
결합되여 있다. 다음의것들은 모두 내용결합의 실례들이다. 

실례 1 모둘 p 는 모둘 q 의 명 령 문을 수식한다. 

이러한 실천은 아쌤블리어프로그람작성에 국한되여 있지 않다. 현재는 COBOL 에서 
제거된 동사 alter 는 정 확히 또 다른 명 령 문을 수식 한다. 

실례 2 모둘 p 는 모둘 인내 에서 몇개의 수자적 인 치 환에 의하여 모둘 q 의 국부자료를 
참조 한다. 

실례 3 모둘 p 는 모둘 다의 국부적 인 표식으로 분기 한다. 

모둘 p 와 모둘 q 가 내용적으로 결합되 여 있다고 가정하자. 여 러가지 위험들중의 하 
나는 모둘 q 에 생 긴 임의의 변경은 q 가 새 로운 를파일 러 혹은 아쌤 블리 어에 의하여 재콤 
파일된다고 하여 도 모둘 p 의 변경 을 요구한다는것 이 다. 더우기 모둘 q 를 재 리용함이 없 
이 어 떤 새 로운 제 품에 서 모둘 p 를 재 리용한다는것 은 불가능하다. 두 모둘이 내 용결 합될 
때 그것들은 뗄수없이 련결된다. 
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7. 3. 2. 공틍결합 

만일 두 모둘들이 동일한 대역적 인 자료에 접근한다면 그 두 모둘은 공통결합된다. 
그에 대 하여 그림 7-9 에 보여 주었 다. 인수들을 넘 겨 주어 서 로 자료통신을 진행할 대 신 
에 모둘 cca 와 ccb 는 대역 변수 variable ) 값을 호출하여 변경시킬수 있다. 이것이 
일어 날수 있는 가장 일반적인 상황은 모둘 cca 와 모둘 ccb 가 모두 같은 자료기지에 접 
근하고 또 동일한 기 록에 대 하여 읽 기 쓰기 를 진행할수 있는 경 우이 다. 공통결 합에 있 어 
서는 두 모둘이 자료기지에 대한 읽기쓰기를 할수 있어야 한다. 만일 자료기지접근방식 
이 읽기전용방식 이 라면 공통결합방식 이 아니 다. 그러 나 C ++ 나 Java 의 수식 어 public 의 리 
용을 비롯하여 공통결합을 실현하는 다른 방법들도 있다. 



그림 7-9. 공통결합 

이러한 결합형태는 많은 리유로 하여 좋은것이 못된다. 그것은 첫째로，결과코드를 
사실상 읽 을수 없기때 문에 구조화프로그람작성 과 모순된 다. 그림 7-10 에 있는 의 사코드 
토막을 생각해 보자. 


while (global variable = = 0) 

{ 

if (argument xyz >25) 
module 3 (); 
else 

module 4 (); 

} 

그림 7-10. 공통결 합을 반영한 의 사코드 

만일 global variable 이 대 역변수이 라면 그 값은 module 3 ， module 4 혹은 그것 들에 의 
하여 호출되는 임의의 모둘에 의하여 변경될수 있다. 어떤 조건에서 순환이 종결되는가 
를 결정하는것은 자명한 문제 가 아니 다. 즉 만일 실시간오유가 발생한다면 수많은 모둘 
들가운데서 임의의 한 모둘이 global variable 의 값을 변경시켰을수 있기때문에 발생한 오 
유를 수정 하는것 은 어 려 울것 이 다. 
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둘째로, 모둘들이 그것들에 대한 읽기가능성에 영향을 주는 부작용을 가지고 있을수 
있다. 실례로 edit this transaction (record 7) 을 생각해 보자. 만일 공통결합이 있다면 이 호 
출은 바로 record 7의 값뿐만아니 라 그 모둘에 의 하여 접 근될수 있는 임의의 대 역 변수를 
변경시 킬수 있다. 한마디 로 전체 모둘이 정 확히 그것 이 무엇을 하는가를 밝혀 내 기 위하 
여 읽어 져야 한다. 

셋째로, 만일 한 모둘에서 대역변수의 선언에 대하여 유지정비변화가 진행된다면 그 
대 역변수에 접 근할수 있는 매 개 모둘이 변경 되 여 야 한다. 더우기 모든 변경 들은 모순이 
없어야 한다. 

넷 째 로, 모둘이 재 리 용될 때 마다 대 역 변수들의 동일 한 목록이 제 공되 여 야 하기 때 문 
에 공통결 합된 모둘은 재 리용하기 힘 든것 이 다. 

다섯째 로, 잠재적 으로 가장 위험한 문제 로서 공통결합의 결과로 어떤 모둘은 그것 이 
요구하는것보다 더 많은 자료를 로출시킬수 있게 된다. 이것은 자료접근을 조종하려는 
그 어떤 시도도 좌절시키며 극단한 경우에는 콤퓨터범죄를 초래할수 있다. 많은 형 태의 
콤퓨터범죄들은 일정한 형태의 공모결탁을 필요로 한다. 잘 설계된 쏘프트웨어는 그 어 
떤 프로그람작성 자도 범죄 를 범하는데 필요한 모든 자료나 모둘들에 접 근하지 못하도록 
하여 야 한다. 실례 로 로임지불계산제 품의 검 열인쇄부분을 작성하는 프로그람작성 자는 종 
업원기 록들에 접 근할 필요가 있다. 그러 나 잘 설계 된 제 품에서 그러한 접 근은 배 타적으 
로 읽기전용방식으로 진행되며 따라서 프로그람작성자가 자기의 월로임을 승인없이 변경 
할수 없게 있다. 그러한 변경 을 하자면 프로그람작성 자는 갱 신방식 으로 련관된 기 록들 
에 접 근할수 있는 또 다른 정 직하지 못한 종업 원에 의 거하여 야 한다. 그러 나 만일 제 품 
이 잘 설계 되 지 못하고 모든 모둘이 갱 신방식 으로 된 로임지 불명 부자료기 지 에 접 근할수 
있다면 단독으로 행동하는 비도덕적인 프로그람작성자가 자료기지에 있는 임의의 기록을 
승인없 이 변경할수 있 다. 

비 록 앞에서 렬거 한 리유들이 대 다수의 대 담한 독자들을 제외한 모든 사람들이 공통 
결합을 리용하지 못하게 할것을 요구한다고 할지라도 공통결합이 개별적인 선택보다 더 
좋은 경 우들이 존재한다. 실례 로 원유저 장랑크들에 대 한 콤퓨터지 원설계 를 수행하는 제 
품에 대하여 생각해 보자 [Schach and Stevens - Guille , 1979]. 탕크는 높이, 직경，탕크가 
받게 될 최대바람속도，절 연두께 와 같은 수많은 서술자들로 렬거되게 된다. 서술자들은 
초기화되여야 하지만 그에 따라 값에서는 변경되지 말아야 한다. 그리고 제품에 있는 대 
부분의 모둘를은 서술자들의 값에 접근할 필요가 있다. 55개의 탕크서술자가 있다고 가 
정하자. 만일 이 모든 서술자들이 매개의 모둘에 인수로서 넘어 간다면 매개 모둘의 대 
면부는 적 어도 55개의 인수들로 구성될것 이며 오유를 범할 가능성 은 크다. 인수들에 대 
한 엄격한 검 사를 요구하는 Ada 와 갈은 언어 들에서 도 동일한 류형 을 가진 두 인수들은 
여 전히 호상 교체 될수 있 으며 형검 사기 에 의하여 검 출되 지 못하는 오유가 있을수 있 다. 

한가지 해결책은 모든 탕크서술자를 자료기지에 넣는것이며 한 모둘이 모든 서술자 
의 값들을 초기화하고 반면에 다른 모든 모둘이 읽기전용방식으로 배 타적으로 자료기지 
에 접 근하는 방식 으로 제 품을 설계하는것 이 다. 그러 나 만일 규정된 실현언어 가 유용한 
자료기지관리체계와 대화할수 없는것으로 하여 자료기지해 결방안이 실천적 인 방도로 되 
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지 않는다면 하나의 대 안은 조종방식 으로서 만 공통결 합을 리용하는것 이 다. 즉 제 품은 55 
개 의 서 술자가 한개 의 모둘에 의하여 초기 화되 지 만 그 어 떤 다른 모둘도 서 술자의 값을 
변경시키지 않도록 설계되여야 한다. 이러한 프로그람작성형식은 쏘프트웨어에 의하여 
시 행되는 자료기지해결방안과는 달리 관리 자에 의하여 시 행되 여 야 한다. 따라서 공통결 
합의 리용과 관련 한 그 어 떤 좋은 다른 방도가 없는 경 우에 대 하여 서 는 관리 자에 의한 
세밀한 감독에 의하여 일 련의 위 험들을 줄일수 있다. 그러 나 보다 좋은 해결책은 7.6 에 
설명 되 는바와 같이 정 보은페 를 리 용하여 공통결 합을 미 리 방지 하는것 이 다. 

7. 3. 3. 조종결합 

만일 한 모둘이 조종요소를 다른 모둘에 넘긴다면 그 두 모둘들은 조종결합된다. 즉 
한 모둘은 명백히 다른 모둘의 론리를 조종한다. 실례로 한 기능코드가 론리적인 응집도 
를 가진 어떤 모둘에 넘겨 질 때 조종이 넘겨 진다 (7.2.2). 조종결합의 또 다른 설계는 조 
종스위치가 하나의 인수로서 넘겨 지는 경우이다. 

만일 모둘 p 가 모둘 다를 호출하고 모둘 q 가 모둘 p 에 《 나는 나의 과제를 끝낼수 없 
다》라는 표식 을 되돌려 넘 겨 주게 되면 모둘 q 는 자료를 넘 겨 준다. 

그러 나 만일 표식 이 《 나는 나의 과제 를 끝낼수 없다. 따라서 오유통보문 ABC 123 를 
써 넣 으라.》라는것 을 의 미 한다면 모둘 p 와 다는 조종결 합된 다. 달리말하여 만일 모둘 q 가 
정보를 모둘 p 에 되돌려 넘겨 주고 모둘 p 가 그 정보를 받은 결과로서 어떤 동작을 취해 
야 할것인가를 결정한다면 모둘 q 는 자료를 넘겨 준다. 

조종결 합에 의하여 발생하는 기 본난관은 두 모둘들이 독립 이 아니 라는것 이 다. 즉 호 
출된 모둘 q 는 모둘 p 의 내 부구조와 론리 를 알고 있 어 야 한다. 결 과 재 리용가능성 은 줄 
어 든다. 이 밖에 조종결 합은 일 반적 으로 론리적 인 응집 도를 가진 모둘과 련관되 는데 론 
리 적 인 응집 도와 관련 하여 난관들이 존재하게 된 다. 

7. 3. 4. 스램프결합 

일부 프로그람작성 언어들에 서는 part number , satellite altitude 혹 은 degree of 
multiprogramming 와 같은 단순한 변수들만이 인수들로서 넘겨 질수 있 다. 그러 나 많은 언 
어 들은 또한 기 록들이나 배 렬 들과 갈은 자료구조들이 인수들로서 넘 어 가는것 을 지 원한 
다 . 이 와 같은 언 어 들 에 서 타 당 한 인 수들 에 는 part record , satellite coordinates 혹 은 
segment table 이 포함된다. 만일 하나의 자료구조가 인수로 넘겨 지지만 호출된 모둘이 그 
자료구조의 일부 개별적요소들에 대해서만 작용한다면 이 두개의 모둘들은 스탬프결합 
된 다. 

실 례 로 호 출 calculate withholding(employee record ) 를 생 각 해 보 자 . 전 체 calculate 
withholding 모둘을 읽지 않고서는 모둘이 employee record 의 어느 마당에 접근하는가 또는 
어느 마당을 변경시키는가 하는것이 명백치 않다. 종업원들의 로임을 명백하게 넘겨주 
는것은 공제액을 계산하는데서 필수적이지만 종업원의 집전화번호가 이 목적에 어떻게 


196 




필요되는가 하는것을 아는것은 힘들다. 그대신 공제액을 계산하기 위하여 실제적으로 필 
요한 마당들만이 모둘 calcuate wkhholding 에 넘 어 가야 한다. 결과적 인 모둘 특히 그의 
대면부는 더 리해하기 쉬울뿐만아니라 공제액을 계산하는데 필요한 여러가지 다른 제품 
들에 서 재 리용할수 있을것 갈다(이 에 대 한 다른 내 용을 알자면 다음의 《 알고 싶은 문 
제》를 보시 오). 


알:2 싶 e ©제 

4개 혹은 5개 의 각이한 마당들을 하나의 모듈에 넘 기 는것 은 하나의 완전한 기 …을 넘 
기 는것 보다 더 시 간이 걸릴 수 있 다. 이 상황은 하나의 보다 큰 문제 를 초래한다. I ■(응답 
시간 혹은 공간제한과 같은) 최 량화문제들이 일반적으로 훌륭한 쏘프트웨어공학실 a 이라 
고 간주되는것과 모순될 때 무엇을 해 야 하는가 하는 문제 이 다. 

경험에 의하면 이러한 질문은 흔히 적합치 않는것으로 판명된다. 권고된 방법，. 응답 
시간을 느리게 할수 있지만 이것은 불과 lms 정도로 너무 작아서 사용자들이 알‘: • 낼수 
없다. 그러므로 돈 크누스 (Don Knuth ) 의 최 량화제 1법 칙 즉《 하지 말라!》에 따寒후 성능 
상 리유를 비롯하여 임의의 종류의 최 량화에 대 한 요구는 거의 없다 [ Knuth , 1974]. 

그러 나 최 량화가 실제로 요구된다면 어떻게 하겠는가? 이 경우에 크누스 의 최 ; : 화제2 
법칙이 적용된다. 제2법칙(전문가들만이라고 표제를 단)은 다음과 같다. 《 아직아니 
다!》달리 말하면 우선 적 당한 쏘프트웨 어공학기 법 을 리 용하여 전체 적 인 제 품을 社성한 
다. 그다음 만일 최량화가 실제적으로 요구된다면 무엇이 무엇때문에 변경되고 있 는가를 
세밀히 문서 작성하면서 필요한 변경만 진행한다. 만일 조금이 라도 가능하다면 이 i 한 최 
량화는 경 험 있는 쏘프트웨 어공학자에 의하여 진행 되 여 야 한다. 


호출 calculate withholding (employee record ) 가 엄격히 필요한것보다 더 많은 자료를 
넘겨 주기때문에 아마 훨씬 더 중요한 문제로서 조종되지 않은 자료호출문제들 그리고 
생각컨데 콤퓨터범죄 가 다시금 생길수 있다. 이 문제는 7.3.2 에서 론의되 였 다. 

만일 자료구조의 모든 요소들이 호출된 모둘에 의하여 리용된다는 조건하에 서 하나 
의 자료구조를 인수로서 넘기는것은 아무런 오유도 없다. 실례로 invert matrix (original 
matrix , inverted matrix ) 또는 print inventory record (warehouse record ) 와 같은 호출들은 자 
료기지를 인수로 넘기지만 호출된 모둘들은 그 자료구조의 모든 요소들에 작용한다. 자 
료구조가 인수로 넘겨 질 때 스탬프결합이 존재하지 만 일부 요소들만이 호출된 모둘에서 
리 용된 다. 

하나의 미묘한 형식의 스탬프결합은 C 혹은 C ++ 와 같은 언어들에서 하나의 레코드에 
대 한 지 적 자가 인수로서 넘 겨 지 는 경 우에 발생 할수 있 다. 호출 check altitude (pointer to 
position record ) 를 고찰하자. 척 보기 에는 넘겨 지는것은 하나의 단순한 변수이 다. 그러 나 
호출된 모둘은 pointer to position record 에 의 하여 지 적된 position record 의 모든 항목들에 
접근한다. 잠재적인 문제들로 인하여 지적자가 인수로 넘겨 질 때마다 결합을 세밀히 조 
사해 보는것이 좋다. 
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7. 3. 5. 자료결합 


만일 모든 인수들이 갈은 종류의 자료항목들이라면 두 모둘은 자료결합된다. 즉 매 
인수는 단순한 인수이거나 모든 요소들이 호출된 모둘에 의하여 리용되는 하나의 자료구 
조이 다. 그 실 례 들로는 display time of arrival(flight number), compute product(first number, 
second number, result) 그리 고 determine job with highest priority(job queue) 들이 있다. 

자료결 합은 하나의 바람직한 목표이 다. 그것 을 부정 적 인 방법 으로 실현하기 위하 
여 만일 어떤 제품이 오직 자료결합을 나타낸다면 내용, 공통， 조종 그리고 스탬프 결 
합에서의 난관들은 생기지 않을것이다. 보다 더 공정적인 견지에서 보면 만일 두 모 
둘이 자료결 합된다면 하나의 모둘에 대 한 변경 이 다른 모둘에 서의 회 귀오유를 적 게 
발생 시킬수 있기때 문에 유지 정 비 가 더 쉽다. 다음의 실 례 들은 결 합의 일정한 측면들 
을 보여 준다. 


7. 3. 6. 결합의 실례 

그림 7-11 에 있는 실례를 고찰해 보자. 릉에 있는 수자들은 그림 7-12 에서 보다 더 
상세히 정의되는 대면부들을 나타낸다. 실례로 모둘 p 가 모둘 q (대면부 1) 를 호출할 때 
그것은 하나의 인수 즉 비행기류형을 넘긴다. 모둘 q 가 모둘 p 에 조종을 넘길 때 그것은 
상태 기발표식 을 되 돌려 넘 겨 준다. 그림 7-11 과 7-12 의 정 보들을 리용하여 매 모둘쌍들 
사이의 결합이 추론될수 있다. 그 결과를 그림 7-13 에 보여 주었다. 

그림 7-13 에 있는 일부 입력점들은 명백하다. 실례로 p 와 q (그림 7-11 에 있는 대면 
부 1) 사이 그리고 r 와 t (대면부 5) 사이， s 와 U (대면부 6) 사이의 자료결합은 하나의 단순한 
변수가 매개 방향으로 넘겨 진다는 사실에 대한 직접적인 결과이다. 만일 p 로부터 s 로 
넘겨진 부분품목록에 있는 모든 요소들이 리용되거나 갱신되면 p 와 s (대면부 2) 사이의 
결 합은 자료결 합으로 될수 있다. 그러 나 만일 s 가 목록의 일정한 요소들에만 작용한다면 
그것은 스탬 프결합이 다. q 와 s (대면부 4) 사이의 결합은 이와 비슷하다. 그림 7-11 과 7-12 
의 정 보가 여 러 가지 모둘들의 기 능을 완전히 설명하지 못하고 있기때 문에 결 합이 자료결 
합인가, 스탬 프결 합인가 하는것 을 결정할 방도는 없 다. q 와 r (대 면부 3) 사이의 결합은 기 
능 코드가 q 로부터 r 에 로 넘겨 지기때 문에 조종결합이 다. 

아마 좀 놀라운것은 그림 7 -D 에 공통결합이 라고 표시된 세개의 입 력점들이 다. 그림 
7-11 에서 제 일 멀리 떨어 져 있는 세개의 모둘쌍들 즉 p 와 t , p 와 U , 호와 U 는 처 음에는 
그 어떤 방향으로 결합되지 않는것 같이 보인다. 결국 그것들을 련결하는 대면부가 없다. 
그리하여 공통결합은 물론 그것들사이의 결합에 대 한 착상은 일정한 설명 을 요구한다. 
그 대답은 그림 7-11 의 오른쪽에 있는 주해 즉 p , t , U 가 갱 신방식 으로 동일한 같은 자 
료기 지 에 접 근한다는 주해 에 있다. 그 결과는 수많은 대 역변수들이 세개의 모둘들에 의 
하여 변화될수 있으며 그것들은 쌍방향으로 공통결합한다는것 이 다. 
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7. 3. 7. 결합의 중요성 

결합도는 중요한 척도이다. 만일 모둘 p 가 모둘 다에 단단히 결합된다면 모둘 p 
니떠한 변경은 모둘 다에 대한 대응하는 변경을 요구할수 있다. 만일 이 변경이 
나 유지 정 비 단계 에 서 요구한대 로 진행된다면 결과적 인 제 품은 기능을 정 확히 여 
다. 그러나 그 단계에서의 전진속도는 결합이 보다 더 느슨해 진 경우에 진행폭 
가 떠질것 이다. 다른 한편 만일 그때 필요한 변경 이 모둘 q 에서 진행되지 않슨 
■에 오유가 저절로 나타나게 될것이다. 가장 좋은 경우에 콤파일러나 련결프로그 
무엇 인가 오유가 생 기거 나 모둘 p 에 대 한 변경 을 시험하는 동안에 오유가 발신 
•는것을 즉시에 통보해 줄것 이 다. 그러 나 보통 일어 나는것은 다음에 진행되는 
이나 제품이 의뢰자의 콤퓨터에 설치된후에 제품이 실패한다는것이다. 두 경나 

- 모둘 p 에 대 한 변경 이 끝난 다음에 오유가 발생한다. 모둘 p 에 대 한 변경 과 .5 
한 스쳐 버 린 해 당한 변경들사이 에는 아무런 명백한 련결도 없다. 따라서」 

하기 어 려울수 있 다. 

모둘들이 높은 응집도와 낮은 결 합도를 가지 게 되 는 설계 가 훌륭한 설계 라고 
히 다음과 갈은 질문이 제 기된다. 즉 그러한 설계 를 어 떻게 실현할수 있는가? 

■ 계와 관련한 리 론적 인 개 념들을 서술하기때 문에 이 문제 에 대 한 대 답은 13장 
:다. 이 과정에 좋은 설계를 확증해 주는 품질들을 더 검토하고 세련시키게 된모 

- 이 장에서 기본적인 정의들은 그림 7-14 에서 매개 정의들이 지적되여 있는 1 
제시된다. 

추상자료형 그 자료형의 실체에 대하여 수행하는 동작을 포함한 자료형 (7.5) 

추상화 불필요한 세부는 삭제 하고 관련 있는 세부는 강조하여 계 단식 으로 세즉 

하는 방법 (7.4.1) 

클라스 계승을 지원하는 추상자료형 (7.7) 

응집도 모듈내에서의 호상작용정도 (7.1) 

결합도 두 모듈사이의 호상작용정도 (7.1) 

자료교갑화 그 자료구조에 대 하여 수행 하는 작용을 포함한 자료구조 (7.4) 




7.4. 자료의 교갑화 

대형콤퓨터용조작체계를 설계하는 문제를 생각해 보자. 명세서에 따라 콤퓨터에 부 
과된 일감은 우선도가 높은 일감, 중간인 일감，우선도가 낮은 일감으로 분류된다. 조작 
체계의 과제는 다음에 어느 일감을 기억장치에 넣어 줄것인가 하는것을 결정하는것이다. 
즉 기 억장치의 일감들중 어느것 이 다음 시 간토막을 차지 하며 또 그 시 간토막이 얼마나 
지속되는가 그리고 디스크호출을 요구하는 일감들중 어느것 이 우선도가 가장 높은가 하 
는것 들을 결정 하는것 이 다. 이 러 한 처 리 계 획 작성 을 진행 하는데 서 조작체 계 는 매 일 감의 
우선도를 고려해 야 한다. 즉 우선도가 높을수록 그 일감에 를퓨터의 자원들이 더 빨리 
할당되여야 한다. 이것을 실현하는 한가지 방도는 매개 일감우선도(/必-夕 nonO ；) 준위에 해 
당한 개 별 적 인 일 감대 기 렬 (job queue)-%： 유지 하는것 이 다. 일 감대 기 렬 은 초기 화되 여 야 한 
다. 그리 고 조작체 계 가 그 일감에 필요한 자원을 할당할것을 결정할 때 대 기렬로부터 일 
감을 제거할뿐아니 라 일감이 기 억， CPU 시 간 혹은 디스크호출을 요구할 때 일감을 일감 
대기렬에 추가하기 위한 기능이 있어 야 한다. 

간단한 문제 로서 기 억호출을 위하여 대 기렬로 작성된 묶음일감들에 대 
한 제 한된 문제를 생각해 보자. 련이은 묶음일감을 위한 세개의 대기렬 이 있는데 매 우 
선도준위에 하나의 일감이 할당된다. 일감은 사용자가 제기할 때 적당한 대기렬에 추가 
되며 조작체계가 일감이 실행될 준비가 되였다고 결정할 때 대기렬로부터 제거되고 기억 
령역이 거기에 할당된다. 

제 품에 서 이 부분은 여 러 가지 각이한 방식 으로 구축할수 있다. 그림 7-15 에 서 보 
여 준 한가지 설계 는 세개의 일감대 기렬중 하나를 처 리 하기 위한 모둘들을 서 술해 주 
고 있다. 의 사코드와 같이 C 언 어 는 고전적 인 파라다임 에 서 제 기 될 수 있 는 일 부 문제 
들을 강조하는데 리용된다. 이 장의 뒤부분에서 이 문제들은 객체지향파라다임을 리용 
하여 해 결 하고 있다. 

그림 7-15 를 고찰해 보자. 모둘 m_l 에서 함수 initialize 」 ob_queue s) 는 일감대기렬의 
초기화에 리용된다. 그리고 모둘 m_2 와 m_3 에 있는 함수 add _job_to_queue 와 remove job 
_from_queue 들은 각각 일 감의 추가와 삭제 에 리 용된 다. 모둘 m_123 에 는 이 일 감대 기 렬 
을 조작하기 위 하여 세 개의 모든 함수들에 대 한 호줄들을 포함한다. 자료교갑화에 집중 
하기 위하여 자리 부족(빈대기렬 로부터 일 감을 제 거 하기 위한 시 도)과 자리넘 침 
( oversow ) (가득찬 대기 렬에 일감을 추가하기 위 한 시도)과 갈은 문제들은 이 장의 나머지 
부분에서와 마찬가지로 여기서는 밝히지 않는다. 

그림 7-15 의 설계 에 있는 모둘들은 일감대기렬에 대 한 작용들이 제품전반에 걸처 분 
산되 여 있기때 문에 낮은 응집도를 가진다. 만일 job_queue 가 실현되 는 방식 (실례 로 선형 
의 목록대 신 기록들의 련결된 목록과 같이：)을 변경 하기 위한 결심을 내 린다면 모둘 m_l, 
m_2, m_3 은 철저 히 수정 되 여 야 한다. 모둘 m_123 도 역 시 변경 되 여 야 한다. 


4) 보다 명백히 하기 위하여 이 에서는 午조화파라다임 이 리용된다는것을 강조하기 위하 
여 initialize _ job _ queue 와 같이 함수이 름에 밑줄표식 을 달았다. 다음 절에서 대 상지향파라다임 
을 리 용할 때 그에 해 당한 방법 을 initializeJobQueue 라고 쓴다. 
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대신 선택되였다고 하자. 그림의 오른쪽에 
며 여 러 가지 작용들을 수행 한다는 점 에 서 
.유한 입 력점과 탈퇴점 그리 고 독자적 인 5 






다. 그림 7-16 에서 모둘 m _ encapsulation 은 자료교갑화 즉 그 자료구조에서 수행될 작용 
들을 포함한 자료구조 이 경우에는 그러한 일감대 기렬의 실현으로 된다. 


m-123 m—encapsulation 


{ 

job job_a, job-b; 


_ 

1 일감대기렬실현 1 

initialize-job 一 queue (); 

add-job-to_queue (job_a); 


^ initialize-job-queue () 

i 

j j L 

remove-job-from-queu© (job-b); 

) : : 


과 add_job-to-queue (job j) 

1 I 


- 1 

remove-job-from-queue (job j) | 比 

:'丄 , —j 


그림 7-16. 자료교갑화를 리용한 조작체 계의 일감대 기렬부분의 설계 

이 시점 에서 하나의 명백한 문제는 자료교갑화를 리용하여 제품을 설계하는 우점은 
무엇 인가 하는것 이 다. 이 질 문에 대 하여 서 는 두가지 방법 즉 개 발의 견지 에 서 와 유지정 
비의 견지에서 대답을 할수 있다. 

7. 4. 1 . 자료교갑화와 제품개발 

자료교갑화는 추상화의 실례이다. 일감대기렬실례로 되돌아 가면 자료구조(일감대기 
렬)는 세개의 련관된 작용들(일감대기렬초기화，대기렬에 일감을 추가, 대기렬에서 일감 
을 제거)과 함께 정의되였다. 개발자는 기록들이나 배렬들의 보다 낮은 준위에서가 아니 
라 일감들과 일감대기렬의 보다 높은 준위에서 문제를 개념화할수 있다. 

추상적개념의 리면에 있는 기본 리론적인 개념은 계단식세련이다. 우선 제품에 대한 
설계는 일감를, 일감대기렬들 그리고 일감대기렬들에서 수행되는 작용들과 갈은 높은 준 
위의 개념들에 의하여 진행된다. 이 단계에서 일감대기렬이 어떻게 실현되는가 하는것은 
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완전히 무의미하다. 일단 완전한 높은 준위의 설계가 얻어 지면 두번째 단계는 자료구조 
와 그 자료구조에 대 하여 수행되는 작용들이 실현될 보다 낮은 준위의 구성요소들을 설 
계하는것 이 다. 실례 로 C 언어 에서 자료구조(일감대 기렬)는 기 록들(구조들) 혹은 배 렬들에 
의하여 실현될것이다. 세개의 작용(일감대기렬초기화，대기렬에 일감을 추가，대기렬에서 
일감을 제거)들이 함수들로서 실현될것 이다. 기본문제점은 이보다 더 낮은 준위를 설계 
할 때 개발자가 일감들, 일감대기렬들 그리고 작용들에 대한 목적한 리용을 완전히 무시 
해 버리는것이다. 따라서 첫번재 단계에서 비록 그 단계에서는 해당한 준위에 대하여 그 
어떤 고려도 하지 않는다고 하여도 보다 낮은 준위 가 존재한다는것을 가정 한다. 그리고 
두번째 단계(보다 낮은 준위의 설계)에서는 보다 높은 준위의 존재를 무시 한다. 보다 더 
높은 준위에서는 자료구조와 일감대기렬의 거동에 관심을 가지게 되며 보다 낮은 준위에 
서는 그 거동의 실현이 1차적인 관심사로 된다. 물론 보다 큰 제품은 많은 추상준위를 
가지게 될것이다. 

각이한 형 태의 추상화가 존재한다. 그림 7-16 을 생각해 보자. 그림 에는 두가지 형 태 
의 추상화가 있다. 자료교갑화 즉 자료구조와 그 자료구조에 대 하여 수행하게 될 작용은 
자료추상화의 실례로 된다. C 언어의 함수 그자체는 처리절차추상화의 실례로 된다. 추상 
화는 개괄하면 단순히 불필요한 세부적인것을 없애고 관계되는 세부적인것들을 강조함으 
로써 계단식세련을 실현하는 수단이다. 자료교갑화는 모형화될 실세계의 실체에 대한 모 
든 측면들을 하나의 단위로 종합하는것으로 정의할수 있다. 이것을 1.6 에서는 개념적독립 
성이라고 하였다. 

자료추상화는 설계가가 자료구조와 자료구조에 대하여 수행되는 작용들의 준위를 고 
찰하고 그 다음에 자료구조와 작용들이 어떻게 실현되는가 하는 세부에 집중할수 있도록 
한다. 이제는 처 리절차추상화로 방향을 바꾸어 C 언어함수 initialize _ job _ queue 의 정의 에 
대한 결과를 고찰하자. 이 효과는 개발자에게 다른 기능 즉 원래 정의된 언어의 부분이 
아닌 기능을 제공함으로써 그 언어를 확장하는것이다. 개발자는 sqrt 혹은 abs 와 같은 
방식으로 initialize _ job _ queue 를 리용할수 있다. 

설계를 위한 처 리절차추상화의 의미는 자료추상화의 의미와 마찬가지 로 위 력하다. 
설계자는 높은 준위의 작용들에 의하여 제품을 개념화할수 있다. 이러한 작용들은 가장 
낮은 준위 에 도달할 때 까지 보다 더 낮은 준위 의 작용들에 의하여 정 의 될수 있 다. 이 러 
한 준위 에서 작용들은 프로그람작성언어 에서 미 리 정의한 구조들에 의하여 표현된다. 매 
준위 에 서 설 계 자는 그 준위 에 적 합한 작용들에 의하여 제 품을 표현 하는데 만 관심 을 가진 
다. 설 계 자는 또한 그 아래 준위 를 무시할수 있 다. 그 준위 는 추상화의 다른 준위 즉 그다 
음의 세 련단계 에서 처 리되게 될것 이 다. 설계 자는 또한 현재 의 준위 를 설계하는 견지 에서 
관련 이 없는 준위 인 그우의 준위 를 무시할수 있 다. 

7. 4. 2. 자료교갑화와 제품의 유지정비 

유지정비의 견지에서 자료교갑화문제를 취급한다면 기본문제는 앞으로 진행될 변경 
들의 영향을 최소화하도록 제품을 변경시키고 설계할 가능성을 줄 제품의 측면들을 파악 
하는것이다. 이와 같은 자료구조들은 변경되지 않을것 갈다. 즉 실례로 만일 제품이 일감 
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대기 렬들을 포함한다면 앞으로의 판본들이 그것들을 병합할것 갈다. 동시 에 일감대기 렬 
들이 실현되는 특정한 방식은 잘 변화될수 있으며 자료교갑화는 그러한 변경들에 대처할 
수 있는 수단을 제공해 준다. 

그림 7-17 은 C ++ 언어 에서 class JobQueue 와 같은 일감대 기렬 자료구조의 실현에 대 
하여 보여 주었다. 그림 7-18 은 그에 대응하는 Java 언어의 실현이다(다음의 《알고 싶은 
문제》에는 그림 7-19 부터 7-26 까지는 물론 그림 7-17 과 그림 7-18 에 있는 프로그람작성 
방식 에 대 한 주석 을 주고 있다). 그림 7-17 혹은 그림 7-18 에서 대 기렬은 25개 의 일감번 
호들로 이루어 진 하나의 배렬로 실현되였다. 첫번째 요소는 queue 。] 이고 25번째 요소는 
queue [24] 이 다. 매개 일감번호는 옹근수로 표현된다. 예 약어 public 는 queuelength 와 queue 
를 조작체계의 어디에서나 볼수 있게 해준다. 결과적인 공통결합은 아주 불충분하게 실 
현될것이며 7.6 에서 수정될것이다. 


알:2 싶 e ©제 

이 책 에 서는 훌륭한 프로그람작성 실 천을 위 하여 자료추상화문제 들을 강조하는 망법 으 
로 그림 7-17 부터 그림 7-26 까지 의 코드실례 를 신중하게 작성하였 다. 실례 로 그림 f _17 과 
7- 18에서 있는 JobQueue 의 정의 에서 수자 25는 분명 히 파라메 터 로 즉 C ++ 언어 비서는 
const 변수로 혹은 Java 언어 에서는 public static final 변수로 코드작성 하여 야 한다. J .한 간 
단히 하기 위 하여 자리부족(빈 대기렬에서 하나의 항목을 삭제 하기 위한 시도)과 다리넘 
침(가득찬 대기렬에 항목을 추가하기 위한 시도)과 갈은 조건들에 대한 검사들은 : :쳐 지 
나가 버렸다. 임의의 실제적인 제품에서 이와 같은 검사들을 포함하는것은 절대적_ .로 필 
수적 이다. 이 밖에 언어 에 고유한 특성들은 최소화하였다. 실례 로 C ++ 프로그람직 양자는 
queueLength 의 값을 하나 중가시 키 기 위 하여 일 반적 으로 

queueLeng 仕 i = queueLength +1 ; 

이 아니라 

queueLeng 仕 i ++; 

를 리용한다. 이와 류사하게 구축자와 파괴 자를 리용하는 문제도 최소화되 였다. 

개괄하여 말한다면 단지 교육적인 목적으로 그림 7-17 부터 그림 7-26 까지 a 드를 
작성하였다. 이 코드들은 임의의 다른 목적 을 위하여 리용되지 말아야 한다. 


그것들은 public 이기때문에 class JobQueue 에 있는 방법들은 조작체계의 그 어느 곳 
에서 나 호출할수 있 다. 특히 그림 7-19 에서 는 class JobQueue 가 C ++ 언어 를 리용하여 방 
법 queueHandler 에 의 하여 어 떻게 리 용될수 있는가 하는것 을 보여 주며 그림 7_20은 이 
에 대 응하는 Java 언 어의 실현이다. 

방법 queueHandler 는 일감대기렬 이 어떻 게 실현되는가 하는 지식 이 없이 JobQueue 에 
대한 방법들인 initialize JobQueue , addJobQueue , remove JobFromQueue 를 호출한다. 즉 class 
JobQueue 를 리 용하는데 필요한 유일 한 정보는 세가지 방법들과 관련한 대면부정 보이 다. 
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// 

// 주의 : 

// 이 코드는 좋은 C ++ 작성방법을 리용하지 않고 C ++ 를 전문하지 않은 독자 
// 들이 리해할수 있도록 씌여 졌다. 또한 간단하게 하기 위하여 자리넘침과 자리 
// 부족검사와 같은 사활적 인 특징들은 빼놓았다. 자세한것은 우의《알고 싶은 
// 문제》를보시오. 

// 

class JobQueue 

{ 

// 속성 

public : 

int queueLength; // 일 감대 기 렬 의 길 이 

int queue[25]; // 대기렬은 25 개까지 일감을 포함할수 있다 

// 방법 

public : 

void initializeJobQueue () 

/* 

* 빈 일감대기렬은 길이가 0이다 
*/ 

{ 

queueLength = 0; 

} 

void addJobToQueue (int jobNumber) 

/* 

* 일감대 기렬의 마감에 일감을 추가한다 
*/ 

{ 

queuefqueueLength] = jobNumber; 
queueLength = queueLength+1; 

} 


int removeJobFromQueue () 

/* 

* jobNumber 를 일감대 기 렬의 앞부분에 보관되 여 있는 일감의 번호와 같 

* 이 설정 하고 일감대 기렬의 앞부분에 있는 일감을 삭제한다. 그리 고 

* j obNumber 를 귀환한다 
*/ 

{ 

int jobNumber = queue[0]; 
queueLength = queueLength-1; 
for ( int k = 0; k< queueLength; k++) 
queuefk] = queue[k+l] 
return jobNumber; 

} 

}// class JobQueue 

그림 7-17. dass JobQueue 의 C ++ 실현 
(public 속성 에 의 하여 제기되는 문제들은 7. 6에서 해결한다. ) 
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// 주의 : 

// 이 코드는 좋은 Java 작성 방법을 리용하지 않고 Java 를 전문하지 않은 독자들 
// 이 리해할수 있도록 씌 여 졌다. 또한 간단하게 하기 위 하여 자리넘 침과 자리부 
// 족검 사와 갈은 사활적 인 특징 들은 빼 놓았다. 자세한것 은 우의 〈〈 알고 싶은 문 
// 제 > 를 보시 오. 

公 

class JobQueue 

{ 

// 속성 

public int queueLength ; 
public int queuef ] = new int [25] 


// 일감대기렬의 길이 
// 대기렬은 25개까지 일감을 
// 포함할수 있다 


// 방법 

public void initializeJobQueue () 

/* 

* 빈 일감대기렬은 길이가 0이다 
*/ 

{ 

queueLength = 0; 

} ᅭ 

public void addJobToQueue (int jobNumber ) 

/* 

* 일감대 기렬의 마감에 일감을 추가한다 

{ 

queuefqueueLength ] = jobNumber ; 
queueLength = queueLength +1; 


public int removeJobFromQueue () 

/* 

* jobNumber 를 일감대 기 렬의 앞부분에 보관되 여 있는 일감의 번호와 

* 같이 설정 하고 일감대 기렬의 앞부분에 있는 일감을 삭제한다. 그리 고 

* jobNumber 를 귀환한다 
*/ 

{ 

int jobNumber = queue [0]; 
queueLength = queueLength -1; 
for ( int k = 0; k < queueLength ; k ++) 
queuefk ] = queue [ k + l ]; 
return jobNumber ; 

} 

}// class JobQueue 


그림 7-18. class JobQueue 의 Java 실 현 
(public 속성 에 의 하여 제기되는 문제들은 7. 6에서 해결한다. ) 





{ 


public: 

void queueHandler () 


int jobA, jobB; 

JobQueue jobQueueJ; 

// 명령문들 

jobQueueJ.initializeJobQueue (); 
jobQueueJ.addJobToQueue (jobA); 
jobB = jobQueueJ.removeJobFromQueue (); 
// 그밖의 명령문들 
}// queueHandler 

}// class Scheduler 


그림 7-19. queueHandler 의 C ++ 실현 


class Scheduler 

{ 

public void queueHandler () 

{ 

int job A, jobB; 

JobQueue jobQueueJ = new JobQueue (); 

// 명령문들 

j obQueueJ.initializeJobQueue (); 
j obQueueJ.addJobToQueue (jobA); 
jobB = jobQueueJ.removeJobFromQueue (); 
// 그밖의 명령문들 
}// queueHandler 


}// dass Scheduler 

그림 7-20. queueHandler 의 Java 실현 

이제 일감대기렬이 현재는 일감번호들의 선형목록으로서 실현되였지만 그것을 쌍방 
향으로 련결된 일감기록들의 목록으로서 재실현하도록 결정되였다고 가정하자. 매개 일 
감기록은 세개의 구성요소를 가질것이다. 즉 그 구성요소들은 앞에서와 마찬가지로 일감 
번호와 련결목록의 앞에 있는 일감기록에 대한 지적자와 그뒤에 있는 일감기록에 대한 
지적자들이 다. 이것은 그림 7-21 와 그림 7-22 에서 보여 주는것 처 럼 각각 C ++ 와 Java 로 
서술되였다. 이제 일감대기렬이 실현되는 방식에 대한 이러한 수정의 결과로서 전반적인 
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쏘프트웨어 제 품에 대 하여서 는 어 떤 변경 을 진행 해 야 하는가? 사실상 JobQueue 만이 변경 
되여야 한다. 그림 7-23 에서는 그림 7-21 의 쌍방향으로 련결된 목록을 리용하여 JobQueue 
에 대 한 C ++ 언 어 실 현 의 륜 곽 을 보 여 주 었 다 . JobQueue 와 제 품 의 나 머 지 ( 방 법 
queueHandler 를 포함하여) 부분들사이의 대면부가 그 어떤 방식으로도 변경되지 않았다 
는 사실 을 강조하기 위하여 실현세 부들을 공개하지 않았다(문제 7.10 을 보라). 즉 세 가지 
방법들인 initalizeJobQueue , addJobToQueue , removeJobFromQueue 은 정 확히 이전과 같 
용 방법 으로 호출된다. 특히 방법 addJobFromQueue 를 불러 낼 때 그것 은 여 전히 
JobQueue 에 옹근수값을 넘겨 주며 removeJobFromQueue 는 비록 일감대기 렬 그자체 가 
전혀 다른 방식으로 실현되였다고 하더라도 JobQueue 로부터 옹근수값을 귀환한다. 결 
국 방법 queueHandler 의 원천코드는 전혀 변경 시 킬 필요가 없 다. 이 리 하여 자료교갑 
화는 제품의 유지정 비 를 간단하게 하고 회귀오유가 발생할 기회를 줄이는 방식 으로 자료 
추상화의 실현을 지원하고 있다. 

class JobRecord 

{ 

public: 

int jobNo; // 일감번호 ( 옹근수 ) 

JobRecord *inFront; // 맨 앞쪽의 일감기록에 대한 지적자 

JobRecord *inRear; // 맨 뒤쪽의 일감기록에 대한 지적자 

}// class JobRecord 

3L 림 7-21. 쌍방향으로 련결된 class JobRecord 의 C ++ 명 세 서 
(public 속성에 의하여 제기되는 문제들은 7.6 에서 해결한다 .) 

class JobRecord 

{ 

public int jobNo; // 일감의 번호 ( 옹근수 ) 

public JobRecord inFront; // 맨 앞쪽의 일감기록에 대한 지적자 

public JobRecord inRear; // 맨 뒤쪽의 일감기록에 대한 지적자 

}// class JobRecord 

그림 7-22. 두 방식으로 련결된 class JobRecord 의 Java 명세서 
(public 속성에 의 하여 제기되는 문제들은 7.6 에서 해결한다 .) 

그림 7-17 과 7-18 그리고 그림 7-19 와 7-20 을 비교하여 보면 이 실례들에 대 한 C ++ 
와 Java 실현들사이의 차이 점 은 본질에 있어서 문장론적 이 라는것 이 명 백하다. 이 장의 나 
머지 부분들에서 우리는 기타 다른 실현에서의 문장론적차이들에 대한 설명과 함께 하나 
의 실현만을 제시하였다. 특히 일감대기렬코드의 나머지는 CH + 로 작성되였고 기타 다른 
모든 코드실례들은 Java 로 작성되였다. 
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class JobQueue 


public: 

JobRecord *frontOfQueue; // 대 기렬의 맨 앞쪽에 대 한 지적 자 
JobRecord *rearOfQueue; // 대기렬의 맨 뒤쪽에 대 한 지적 자 

void initialize JobQueue () 

{ 

/* 

* frontOfQueue 와 rearOfQueue 를 NULL 로 설정하여 일감대 기렬을 

* 초기화한다 
*/ 


} 


void addJobToQueue (int jobNumber) 

{ 

/* 

* 새 일감기 록을 창조하고 jobNo 마당에 jobNumber 를 넣 어 준다. 

* 현재의 rearOfQueue 를 지적하기 위하여(대기렬의 마감에 새 일감을 

* 련결 하여) inFront 항목을 설정한다. 

* inRear 항목을 NULL 로 설 정한다 

* 새 기록을 지적하기 위하여(쌍방향으로 련결을 설정하여) 

* 지적된 기록의 inRear 항목을 현재의 rearOfQueue 로 설정한다 

* 마지 막으로 이 새 기 록을 지 적 하기 위하여 rearOfQueue 를 설정한다. 
*/ 

} 


int removeJobFromQueue () 

{ 

/* jobNumber 을 대기렬의 맨앞에 있는 기록의 jobNo 항목과 같게 설 

* 정한다. 대 기렬의 다음 항목을 지 적 하기 위 하여 frontOfQueue 를 갱 신 

* 한다. 대 기렬의 지 금의 앞에 있는 기 록의 inFront 항목을 NULL 로 

* 설 정한다. 그리 고 jobNumber 를 귀 환한다 
*/ 


} 

}// class JobQueue 


그림 7-23. 쌍방향으로 련결된 목록을 리용한 class JobQueue 의 C++ 일반적실현 


7. 5. 추상자료형 

그림 7-17( 혹은 그림 7-18) 은 일감대 기 렬 class 즉 자료형과 그러 한 자료형 에 대 하여 
수행 하게 되는 작용들의 실현이다. 그러 한 구조를 추상자료형 여&따갔次 쇼比! 次/! 이라고 
부른 다. 

그림 7-24는 이 추상자료형 이 조작체계의 세개의 일감대기렬에 대 하여 C ++ 로 어떻게 
리용할수 있는가를 보여 준다. 세개의 일감대 기렬들은 실체화된다. 즉 highPriorityQueue , 
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mediumPriorityQueue , lowPriorityQueue 로 실체 화된다 (Java 판본에서 는 세 개의 일감대 기 렬들 
에 대한 자료선언에서 문장론적인 차이가 있다.). 명령문 highPriorityQueue , initializeJobQueue 
는《 조작 initializeJobQueue 를 자료구조 highPriorityQueue 에 적 용하는것》을 의 미 하며 다 
른 두개의 명령문들에 대하여도 이와 류사하게 고찰할수 있다. 


class Scheduler 


public: 

void queueHandler () 

{ 

int jobl, job2; 

JobQueue highPriorityQueue; 

JobQueue mediumPriorityQueue; 

JobQueue lowPriorityQueue; 

//명령문들 ^ 

highPriorityQueue.initializeJobQueue (); 
mediumPriorityQueue.addJobToQueue (job 1); 
job2 = lowPriorityQueue .remove JobFromQueue (); 

// 그밖의 명령문들 

}// queueHandler 

}// class Scheduler 

그림 7-24. 그림 7-17 의 추상자료형 을 리용하여 실현한 C ++ 방법 queueHandler 


class Rational 


public int numerator; 
public int denominator; 

public void sameDenominator (Rational r, Rational s) 

{ 

// r 와 s 를 같은 분모로 통분하는 코드 

} 

public boolean equal (Rational t, Rational u) 

{ 

Rational v, w; 

v=t ； 

w=u; 

sameDenominator (v,w) 

return (v.numerator = w.numerator); 

} 

// 두 유리수를 더하기，덜기，곱하기，나누기방법 

}// class Rational 


그림 7-25. 유리 수의 Java 추상자료형실 현 
(public 속성 에 의 하여 제기되는 문제들은 7. 6 에서 해결한다.) 
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추상자료형은 널리 적용할수 있는 설계도구이다. 실례로 수많은 작용들이 유리수들 
즉 n/d 형식으로 표현될수 있는 수들에 대하여 수행되여 야 하는 제품을 개발한다고 하자. 
여기서 n 과 d 는 옹근수들이고 d 半 0 이다. 유리수들은 하나의 1 차원옹근수배렬의 두개의 
요소 또는 한 클라스의 두개의 속성과 같은 다양한 방식으로 표현될수 있다. 추상자료형 
으로 유리 수들을 실현하기 위하여 자료구조에 대 한 적 합한 표현 이 선택된다. Java 언어 에 
서 그것 은 두개 의 옹근수들로부터 유리 수를 구성 하고 두개 의 유리 수들을 더하거 나 곱하 
는것 과 같은 유리 수들에 대 한 여 러 가지 작용들과 함께 그림 7-25 에 서 와 같이 정 의할수 
있 을것 이 다(그림 7-25 에 서 numerator 와 denominator 와 같은 public 속성 에 의 하여 발생 되 는 
문제들은 7.6 에서 수정될것이다.). 대응하는 C 4+ 언어에서의 실현은 예약어 public 의 배치 
에서 차이난다. 또한 인수가 참조로 넘겨 질 때 &가 요구된다. 

추상자료형 은 자료추상화와 처 리절차추상화를 모두 지원한다 (7.4.1). 이 밖에 제품이 
수정될 때 추상자료형은 변화되지 않는다. 최악의 경우에 추가적 인 작용들은 추상자료형 
에 추가되여야 한다. 따라서 제품개발과 제품의 유지정비의 견지에서 볼 때 추상자료형 
들은 쏘프트웨 어 개 발자들에 게 는 매 력 있는 도구로 된 다. 

7. 6.정보은 페 

7.4.1 에서 론의된 두가지 형태의 추상화(자료추상화와 처리절차추상화)들은 파나스 
(Pamas) 가 제 기 한 보다 일 반적 인 설 계 개 념 즉 정 보은페 {information hiding ) 의 실 체 들이 다 
[Pamas, 1971, 1972a, 1972b], 파나스의 착상은 장래의 유지정비를 지향하고 있다. 제품이 
설계 되 기전에 앞으로 변경될 가능성 이 있는 실현들에 대 한 목록이 작성 되 여 야 한다. 그 
때 모둘들은 결과적인 설계의 실현세부들이 다른 모둘들에게 숨겨 지도록 설계되여야 한 
다. 그러 므로 장래 에 진행 될 매 변경 들은 하나의 특정한 모둘에 국한되 게 된다. 원래 의 
실현결정에 대한 세부들은 다른 모둘들에서는 볼수 없게 되므로 설계를 변경시키는것은 
그 어떤 다른 모둘들에는 명백히 영향을 주지 않는다(정보은페에 대하여 좀 더 자세히 
알자면 다음에 서 술되 여 있는《 알고 싶은 문제〉〉를 보시 오). 


알:2 싶 e ©제 

용어 정보은페 (/«/ w 7 naft _ o « hiding ) 는 무엇인가 잘못된 이름인것 같다. 왜냐하면 8：페하 
여야 할것은 정보가 아니 라 실현세부이기때문에 보다 정확하게 서술하면 세부은폐 details 
hiding ) 라고 해야 할것 같다. 


이러한 착상이 실천적으로 어떻게 리용될수 있는가를 보기 위하여 그림 7-17 에서의 
추상자료형실현을 리용한 그림 7-24 를 고찰하자. 추상자료형 을 리용하는 기 본리유는 일 
감대기렬의 내용들이 그림 7-17 의 세 조작들중 어느 하나를 불러냄으로써만 변경될수 있 
게 하는것 이 다. 유감스럽 게 도 그 실현의 본질은 일감대 기렬들이 다른 방식 들로 변경될 수 
있게 하는것과 갈다. 






속성들인 queueLength 와 queue 는 둘다 그림 7_17에서 public 로 선언되여 있고 따라서 
queueHandler 안에서 접근가능하다. 결과 그림 7신4에서 highPriorityQueue 를 변경시키기 위 
하여 queueHandler 안의 그 어디에서나 

highPriorityQueue . queue [7] = —5678; 

과 같은 대 입명 령문을 리용하는것은 C ++ (혹은 Java ) 에서 완전히 합법적 이 다. 달리 말하 
여 일 감대 기렬의 내 용들은 추상자료형 의 세 조작들중 아무것 도 리용하지 않고 변경 시 킬 
수 있다. 응집도를 낮추고 결합도를 강하게 하는것과 관련하여 가질수 있는 의미외에도 
관리 자는 제품이 7.3.2 에서 설명한것처 럼 콤퓨터범죄를 범할수 있다는것을 인식하여 야 
한다. 

class JobQueue 

{ 

// 속성 

public int queueLength; 
public int queue[] = new int[25] 


// 방법 

public void initializeJobQueue () 

{ 

// 그림 7-17 에서 변화되지 않은 방법의 체부 

} 


// 일감대기렬의 길이 
// 대기렬은 25개까지 일감을 포함 
// 할수 있다. 


public void addJobToQueue (int jobNumber) 

{ 

// 그림 7-17 에서 변화되지 않은 방법의 체부 

} 

public int removeJobFromQueue () 

{ 

// 그림 7-17 에서 변화되지 않은 방법의 체부 

} 

}// class JobQueue 


그림 7-26. 그림 7-17，7-18， 7-21, 7-22, 7_25의 문제들을 정확히 
하는 정보은폐를 진행한 C ++ 추상자료형실현 

다행 히 한가지 출로가 있 다. C ++ 와 Java 의 설 계 자들은 클라스명 세 서안에 서 정 보은페 
를 규정 하였다. 이것 은 그림 7-26 에서 C ++ 에 관하여 보여 주었 다 (Java 와의 문장론적 차이 
는 이전과 같다.). 

public 에서 private 로 속성들의 가시성수식 어를 변경 시 킨것외 에는 그림 7_26은 그림 
7-17 과 같다. 지 금 다른 모둘들에 서 볼수 있는 유일 한 정 보는 JobQueue 가 하나의 클라 
스류형 이며 명기된 대 면부를 가진 세 동작들은 결과적 인 일감대기렬에 작용할수 있다는 
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것이다. 그러나 일감대기렬들이 실현되는 정확한 방도는 private 화되였다. 즉 외부에서 볼 
수 없다. 그림 7-27 에 있는 도표는 private 속성을 가진 클라스가 C ++ 나 Java 사용자가 완 
전한 정보은폐를 가진 추상자료형을 어떻게 실현할수 있는가 하는것을 보여 준다. 

정 보은페기 법은 또한 7.3.2 의 마감에서 언급한것처 럼 공통결합을 방지하는데 리용될 
수 있다. 여 기서 설명된 제 품 즉 55개의 서 술자들에 의하여 명 기된 페트롤렌저 장탕크들 
을 위 한 콤퓨터지 원설계 도구에 대 하여 다시 생 각해 보자. 만일 제 품이 서 술자를 초기 화 
하기 위한 private 작용들을 가지 고 실현된다면 그 어 떤 공통결 합도 없 다. 이 해 결형 식 은 
다음절에서 설명되는것 처 럼 객체 들이 정보은폐 를 지 원하기때 문에 객체지향파라다임 으로 
특징지어 진다. 이것은 객체기법을 리용하는 또 하나의 우월성으로 된다. 

일감처 러 계획 작성 프로그람 JobQueue 



그림 7-27. private 속성 으로 정 보은폐 를 진행한 추상자료형 의 표현 
(그림 7-24 와 함께 그림 7-26 ) 


7. 7. 객 체 

이 장의 앞부분에서 언급된것처 럼 객체들은 단순히 그림 7-28 에 보여 준 과정에서 
다음의 단계 로 된다. 객체들에 대 하여서는 그 어떤 특별한것 이 없다. 즉 그것들은 추상자 
료형 이 나 정 보적인 응집도를 가진 모둘들만큼 일 반적 인것 이 다. 객체의 중요성은 그것 들 
이 자기자신의 추가적인 속성들은 물론 그림 7-28 에 있는 자기 선조들의 모든 속성들을 
가지고 있다는것이다. 
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높은 응집 력파 낮은 결 합력 을 가진 객체 (7. 9 절 ) 
it 

객체 (7.7 절 ) 
ft 

정보은폐 ( 7.6 절 ) 

介 

추상자료형 ( 7.5 절 ) 
fr 

자료교갑화 (7. 4 절 ) 
t 

높은 응집력과 낮은 결합력을 가진 모둘 (7.2 절， 7.3 질 ) 
모들 ( ᅮ . 1 절 ) 


그림 7-28. 7 장의 기본개념 

객체 에 대 한 불완전한 정의는 객체가 추상자료형의 실체 이라는것 이 다. 즉 제품은 추상자 
료형들에 의하여 설계되며 제품의 변수들(객체들)은 추상자료형들의 실체 이 다. 그러 나 객체를 
추상자료형의 실체 라고 정의한것은 너무 단순하다. 이와 관련하여 무엇 인가 더 필요하다. 즉 
Simula 67 [Dahl and Nygaard, 1966] 에서 처음으로 소개된 개념인 계승(切뇨?■功이 필요 
*1 ■게 된다. 계 승은 Smalltalk [Goldberg and Robson, 1989], C++ [Stroustrup, 1991], Eiffel 
[Meyer, 1992b], Ada95 [ISO/IEC 8652, 1995], Java [Flanagan and Loukides, 199 기와 같은 
모든 객체지향프로그람작성언어들에 의하여 지원된다. 계승의 리면에 있는 기 본착상은 
새로운 자료형들이 령상태에서부터 정의되는것이 아니라 이전에 정의된 형들의 확장으로 
정의될수 있다는것이다 [Meyer, 1986]. 

객체지향언어에서 클라스 ( cto 功는 계승을 지원하는 추상자료형으로 정의할수 있다. 
그때의 객체는 클라스의 실체 로 된다. 클라스들이 어 떻게 리용되는가를 알기 위하여 다 
음의 실례를 고찰하자. HumanBeing 을 콜라스로, Joe 를 그 클라스의 실체인 객체라고 정 
의 하자. 매 HumanBeing 은 나이 와 키 와 같은 일정 한 속성 을 가지 고 있으며 값들은 객체 
Joe 에 대 하여 설명할 때 그 속성 들에 대 입할수 있다. 이제 Parent 를 HumanBeing 의 부분 
클라스(새뇨/따功(도출클라스 또는 파생 클라스; derived class ) 로_ 정 의 한다고 가정 하자. 이 것 
은 Parent 가 HumanBeing 의 모든 속성들을 가지고 있으며 그밖에 제일 나이 많은 자식 (맏 
자식 )의 이 름과 아이 들의 수와 같은 자기 고유의 속성 들을 가질 수 있 다는것 을 의 미한다. 이 
에 대 해서 는 그림 7-29 에서 설명 하고 있다. 객체지향용어 에서 는 Parent isA HumanBeing 이 
라고 한다. 이 리하여 그림 7-29 에 서 화살표는 방향이 잘못된것 같다. 사실 상 화살표는 
쇼以관계 를 나타내 고 있고 따라서 파생클라스로부터 기 초믈라스에 로 가리킨다(계 승을 표 
시 하기 위하여 열린 화살을 리용한것 은 UML 규정 이 다. 그리 고 또 다른것 은 클라스명 들이 
매 개 단어의 첫 글자를 대 문자로, 굵은체로 나타낸다는것 이 다. UML 은 12 장에서 좀 더 
자세 히 론의한다.). 

클라스 Parent 는 기초클라스 HumanBeing 의 파생클라스(혹은 부분콜라스)이기때문에 
HumanBeing 의 모든 속성 들을 계승한다. 만일 Fred 가 객체 이 고 클라스 Parent 의 실체 이 
라면 Fred 는 Parent 의 모든 속성들을 가지 고 있으며 또한 HumanBeing 의 모든 속성들을 
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계 승한다. 



(도출문라스) 


그림 7-29. 도출된 형들과 계승 


그림 7-30 에 Java 의 실현을 보여 주었다. C++ 판본은 Private 와 Public 수식어들의 배 
치가 다르다. 또한 이 실례에서 Java 문법 extends 은 C++ 에서 : public 로 교체된다. 


class HumanBeing 

{ 

private int age; 
private froat height; 

// HumanBeing 에 대한 조작의 public 선언 
}// class HumanBeing 


class Parent extends HumanBeing 

{ 

private string nameOfOldestChild; 
private int numberOfChildren; 

//Parent 대 한 조작의 public 선 언 
}// class Parent 

그림 7-30. 그림 7-29 의 Java 실현 

계승의 성질은 모든 객체지향프로그람작성언어들의 본질적인 특성이다. 그러나 계 
승이나 클라스의 개념은 C, COBOL 혹은 FORTRAN 과 같은 고전적인 언어들에 서는 
지원되지 않는다. 따라서 객체지향파라다임은 이러한 대중적인 언어들에 의하여 직접 
실현될수 없다. 

객체지 향파라다임의 용어 에는 그림 7 - 29에 있는 Parent 와 HumanBeing 사이의 관계를 
고찰하기 위한 두가지 서 로 다른 방법 들이 있 다. Parent 는 HumanBeing 의 특수화라고 말 
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할수 있 으며 혹은 HumanBeing 이 Parent 의 일 반화라고 말할수 있 다. 특수화와 일 반화외 
에 도 콜라스는 두가지 다른 기 본관계 즉 집 합과 결합을 가진다 [ Blaha , Premerlani , and 
Rumbaugh , 1988]. 집 합 ( aggregafew ) 은 클라스의 구성요소를 의미 한다. 실례 로 클라스 
PersonalComputer 는 구성 요소들 즉 CPU , Monitor , Keyboard , Printer 등으로 구성 되 
여 있다. 이것 을 그림 7-31 에 보여 주었 다(집 합을 보여 주기 위하여 다이 아몬드글자체(보 
통 활자들중에 서 가장 작은 활자들중의 하나)를 리용하는것 은 또 하나의 다른 UML 규정 
이다). 이에 대해서는 새로운것이 전혀 없다. 즉 어떤 언어가 C 에서 struct 와 같은 기록들 
을지원할 때마다 이러한 현상이 발생한다. 그러나 객체지향의 범위내에서 관련항목들을 
묶는데 리용되 며 결과적 으로 재 리용가능한 클라스를 생 성한다 (8.1). 



그림 7-31. 집합의 실례 

결합 ( awodaton ) 은 두개의 명백한 련관이 없는 클라스들사이의 일종의 관계를 의미 
한다. 실례로 렌트겐의사와 미술가사이에는 그 어떤 련관이 없는것 같다. 그러나 MRI 기 
계 가 어 떻게 동작하는가를 설명한 책의 도식들을 그리는것과 관련하여 렌트겐의사는 미술 
가에게 의견을 물어 볼수 있다. 결합은 그림 7-32 에 보여 주고 있다. 

이 실례 에서 결합의 본질은 단어 상담 ( CO / MM / to ) 에 의 하여 지적된다. 이 밖에 검 은 삼각 
형은 결합의 방향을 가리킨다. 결국 발목이 부러진 미술가는 렌트겐의사와 상담할수 






다른 객 체 지 향언어 들에 서 와 마찬가지 로 Java 와 C ++ 표기 법 에 서 의 한가지 측면은 작 
용과 자료의 등가성 을 명백 히 반영한다. 우선 기록을 지 원하는 고전적 인 언어 실례 로 
C 언어를 고찰하자. record _ l 은 struct (기록)이고 field _2 는 클라스내의 마당이 라고 가정 
하자. 그러 면 마당은 끄군0)선_1고61(1_2로 간주된 다. 즉 . 은 기 록내 에 서 성 원관계 를 나타 
낸다. 만일 function _3 이 C 모둘내 에서의 하나의 함수이 라면 function _30 은 그 함수의 호 
줄을 의 미 한다. 

대조적 으로 ClassA 가 속성 attributeB 와 방법 methodC 를 가진 하나의 클라스라고 가 
정하자. 더 나아가서 ourObjcct 가 ClassA 의 실체 라고 가정하자. 그러면 마당은 ourObject . 
attributeB 로 간주된 다. 그리 고 ourObject . methodC () 는 이 방법 의 호출을 나타낸 다. 그리 하 
여 .은 성원요소가 속성이든 방법이든 객체내에서의 성원관계를 나타내는데 리용된다. 

객 체들(혹은 클라스들)을 리용하는 우월성 은 정 확히 자료추상화와 처 리절차추상화를 
비 롯한 추상자료형 을 리용하는데 서 의 우월 성 이 다. 이 밖에 클라스들의 계 승측면 은 자료추 
상화의 그이상의 계층을 제공하며 보다 쉽고 보다 적은 오유를 가지는 제품개발을 할수 
있도록 한다. 또 하나의 우월성은 다음절의 주제로 되는 다형성과 동적맺기를 계승과 결 
합하는데로부터 나온다. 


7. 8. 계승, 다령성과 동적맺기 

어떤 를퓨터의 조작체계가 파일을 열기 위하여 호출된다고 하자. 파일은 여러가지 각이 
한 매체들에 저장될수 있다. 실례로 파일은 디스크파일, 레프파일 혹은 유연성자기디스크파 
일일수 있다. 구조화파라다임을 리용하면 세개의 함수들 즉 open _ disk _ file ， open _ tape _ file , 
open _ diskette _ file 이 있을수 있다. 이에 대하여서는 그림 7_33의 자)에 보여 주었다. 만일 
my _ file 이 파일 로 선언되 면 그것 이 디 스크파일 인지，테 프파일 인지 혹은 플로피 자기 디 스크 
파일인지를 시험해 보는것이 중요하다. 

반 대 로 객 체 지 향 파 라 다 임 이 리 용될 때 세 개 의 파생 클 라스들 인 DiskFileClass, 
TapeFileClass, DisketteFileClass 를 가진 FileClass 라는 클라스가 정의된다. 이에 대하 
여 그림 7-33 의 L ) 에 보여 주었 다. 여 기서 열린 화살표가 계승을 나타낸다는것을 상 
기 하시 오. 

이제 방법 open 이 어 미클라스 FileClass 로 정의되 고 세개의 파생클라스들에 의하여 
계승된다고 하자. 유감스럽게도 세개의 각이한 형식의 파일들을 여는데 서 로 다른 작용 
들이 수행되여야 하기때문에 이것은 동작할수 없다. 

그 해결책은 다음과 같다. 어미클라스 FileClass 에서 가상적인 방법 open 을 선언한다. 
Java 에서는 이러한 방법을 abstract 로 선언한다. C ++ 에서는 대신 예약어 virtual-!- 리용한 
다. 이 방법의 하나의 특정한 실현은 세개의 파생클라스에서 각각 출현하며 매 방법 은 
그림 7-33 의 L ) 에서 보여 준것처 럼 open 이 라는 동일 한 이름을 가진다. 이제 myFile 이 파 
일 로 선언된다고 하자. 실행시 에 통보문 myFile . open () 이 보내 여 진다. 이제 객 체지 향체계 
는 myFile 이 디 스크파일 인지 , 테 프파일 인지 혹은 플로피 자기 디 스크파일 인지 를 결 정 하고 
open 에 대한 적절한 판본을 호출한다. 
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| 함 _ 4 open_disk_ffle | | 함 ■ ♦ open_tape_file | I 함 수 open_diskette_file I 
I) 



l) 


그림 7-33. 파일열기에 요구되는 작용 
D 구조화실현 , l) Java 표기법을 리용한 객체지향파일콜라스의 계층 

즉 체 계는 실행시 에 객체 myFile 이 클라스 DiskFileClass , 클라스 TapeFileClass 혹은 
클라스 DisketteFileClass 의 실체 인가를 결정하고 자동적으로 정확한 방법을 호출한다. 이 
것은 실행시에(동적으로) 진행되여야 하며 를파일시에는(정적으로) 진행되지 말아야 하기 
때 문에 객체를 적 당한 방법 에 련결시 키는 작용을 동적맺 기(수 binding ) 라고 한다. 더 
우기 방법 open 이 각이한 클라스들의 객체들에 적용될수 있기때문에 그것을 다형성 
一/;; mo 방射 c ) 이 라고 한다. 이 용어 는《많은 형 태》를 의 미한다. 탄소결정 편들이 굳은 금 
강석 들과 무론 흑연을 비 롯한 여 러 가지 각이한 형 태 들로 나타나는것 처 럼 방법 open 도 세 
개 의 각이한 판본으로 나타난다. Java 에 서 이 판본들은 DiskFileClass.open, TapeFileClass. 
open 그리고 DisketteFileClass.open 으로 표시된다 (C++ 에서 .은 두개의 :으로 교체되며 파 
일들은 DiskFileClass::open, TapeFileClass : :open, DisketteFileClass::open 으로 표시된다). 그러 
나 동적 맺 기 로 인 하여 특정한 파일 을 열 기 위하여 어 느 방법 을 호출할것 인가 하는것 을 
결정하는것 은 필요 없다. 대 신 실행시 에 오직 통보문 myFile.open() 만을 보내 는것 이 필요 
하며 체계는 myFile 의 형(클라스)을 결정하고 정확한 방법을 호출할것이다. 

이러한 착상은 바로 abstract ( virtual ) 방법에서 더 유용하다. 그림 7_34에 보여 준바와 
같이 클라스의 계승을 고찰하자. 모든 클라스들은 기 초콜라스로부터 계승에 의해서 파생 
된다. 방법 checkOrder(b:Base) 가 클라스 Base 의 하나의 실체를 인수로서 취한다고 가정하 
자. 그러면 계승, 다형 성，동적맺기의 결과로 checkOrder 를 클라스 Base 뿐만아니 라 그로 
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부터 파생된 임의의 클라스의 인수와 함께 호출하는것은 타당하다. 



여 기 서 필 요한것 은 checkOrder 를 호출하는것 이 며 실 행 시 에 모든것 에 주의 를 돌리 는 
것 이 다. 이 러한 기 법은 쏘 프트웨 어전문가들이 어떤 통보문이 보내여 질 때 인수의 정확 
한 형에는 관심할 필요가 없다는 점에서 아주 강력한 기법으로 된다. 

그러 나 다형성과 동적맺기 는 중요한 결함으로도 된다. 첫째 로，실행중에 특정한 다형 
성방법 들가운데 서 어 느 판본을 호출하겠는가를 콤파일할 때 결 정하는것 은 일 반적 으로 불 
가능하다. 따라서 실패의 원인을 결정하기가 대단히 어려워 진다. 

둘째 로, 다형 성 과 동적 맺 기 는 유지 정 비 에 부정 적 인 영 향을 미 친 다. 유지 정 비 프로그람 
작성 자의 첫째 가는 임 무는 일 반적 으로 제 품을 리해하는것 이 다 (16 장에 서 설 명한바와 같이 
유지정비자는 때로 코드를 작성하는 사람으로 되기도 한다.). 그러나 특정한 방법에 대 
하여 여 러개의 가능성 이 존재하면 곤난하게 될수 있다. 프로그람작성 자는 특정한 코드부 
분을 동적으로 호출하는 방법들에 대해서 가능한껏 모두 고찰해야 하는데 이것은 시간이 
소비되는 과제이다. 이처럼 다형성과 동적맺기는 객체지향파라다임에 우단점을 부가한다. 

1.6 에서 제기한 객체지향파라다임의 우월성에 대한 리유는 개념적 및 물리적독립성 
을 포함하고 있다. 이러한 독립성을 측정하기 위하여 객체의 범위내에서 응집도와 결합 
도의 개념을 다시 검토하여야 한다. 

7.9. 객체의 응집도와 결합도 

객체는 일종의 모둘이다. 결국 응집도가 강하고 결합도가 약한 모둘과 관련하여 7.2 
과 7.3 에서 제기한 문제들은 객체들에도 마찬가지로 적용된다. 이때 객체지향파라다임 안 
에서 특정한 형 태의 응집과 결합이 발생하겠는가 하는 문제 가 제 기된다. 

우선 응집도를 고찰하자 (7.2 에 서 설 명한바와 같이 모둘의 응집 도는 그 모둘에 의하 
여 수행 되 는 작용들이 기 능적 으로 관계 되 는 정 도이 다는것 을 상기하시 오.). 콜라스는 두가 
지 작용을 포함할수 있는데 하나는 계승된 방법 이고 다른 하나는 그 클라스에 고유한 방 
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법이다. 클라스의 응집도는 그러한 기능의 원천과는 관계없이 그 기능자체로부터 결정된 
다. 이것을 고찰하기 위 하여 두 클라스가 같은 기능을 수행 한다고 가정 하자. 그러 나 하나 
의 콜라스는 자기의 상위클라스(계층도에서 그의 선조)로부터 모든 기능을 계승한다. 한 
편 다른 클라스들은 아무것도 계승하지 않는다. 두 클라스가 다 갈은 기능을 수행하기때 
문에 그것들은 갈은 준위의 응집도를 가진다. 달리 말하면 그 어떤 류형의 응집도도 콜라 
스에 특정한것이 아니다. 반면에 응집도는 콜라스를 비롯한 모든 형태의 모둘들에 대하 
여 동등하게 적용된다 [ Schach ，1996]. 

결합과 관련하여서는 우선 계승이 무시된다. 계승이 없는것으로 하여 두 클라스사이의 
결합도는 고전적인 파라다임에서와 같이 결정될수 있다. 실례로 클라스의 속성이 public 로 
정의되면(제품안에서 모든 다른 부분들을 호출할수 있는) 이것은 공통적인 결합을 초래 
할수 있다. 놀라운것은 계승이 새 로운 형 태의 결합을 초래하지 않는다는것 이 다. 즉 결합 
의 결과로 발생하는 결 합의 형 태 들은 고전적 인 파라다임 들에 서 도 역 시 발생 한다고 볼수 
있다 [Binkley and Schach , 1997]. 그러 므로 고전적 인 파라다임과 객체지향파라다임사이 에 
중요한 차이 가 있음에 로 불구하고 객체지향파라다임은 새 로운 형의 응집도이 라든가 결합 
도를 생 성할수 없 다. 

그러 나 객체지향파라다임 에 고유한 여 러 가지 척도들이 제시되 였다. 실례 로 계승나무 
의 높이를 들수 있다 [Chidamber and Kemerer , 1994]. 이러한 일부 척도들은 리론적이고 경 
험 적 인 토대 우에 서 문제 시 되 였 다 [BMdey and Schach , 1996, 1997]. 이 경 우에 는 여 전히 객 
체지 향파라다임쏘프트웨 어 에 동등하게 응용될수 있는 고전적 척도(응집도와 결합도와 같 
은)가 아니 라 특별히 객체지향척 도가 필요하다는것을 보여 준다. 

객체지향파라다임 에 대 한 론의 로 이 장을 결속한다. 

7.10. 객체지향파라다임 

매개 쏘프트웨 어제품을 두가지 방법 으로 고찰할수 있다. 한가지 방법은 국부변수나 
대역변수，인수，동적자료구조，파일 등을 비롯하여 바로 자료들을 고찰하는것 이 다. 다른 
한가지 방법은 처리절차나 함수와 갈은 자료를 처리하는 작용을 고찰하는것이다. 쏘프트 
웨어를 자료와 작용으로 나누어 고찰함으로써 구조화기법은 본질적으로 두 그룹으로 갈 
라 진 다. 작용지향기법 은 우선 제 품의 작용들을 고찰한다. 자료는 2차적 인 문제 로 된 다. 
자료는 제품에 대 한 작용을 심도 있게 해석한 다음에만 고찰된다. 반대 로 자료지향기술 
읔 제 품의 자료를 중요시 한다. 한편 작용들은 자료의 틀거 리안에 서 만 고찰된 다. 

자료지향이 나 작용지향방법 의 기 본 약점 은 자료나 작용이 같은 자격 을 가지 는 두가 
지 측면을 가진다는것이다. 다시말하여 작용이 실행되지 않으면 자료는 변경될수 없고 
자료와 결합되지 않은 작용에 대하여서도 생각할수 없다는것 이 다. 따라서 자료와 작용에 
대하여 똑같이 중시하고 고찰해야 한다. 객체지향기법은 이러한 고찰에 기초하고 있다. 
결국 객체는 자료와 작용을 모두 포함하고 있다. 객체가 추상자료형(더 정확하게 콜라스) 
의 한가지 실례 이라는것은 이 미 알고 있다. 그러므로 자료와 그러한 자료를 처 리하는 작 
용은 하나로 병 합시켜 보아야 한다. 객체 에서 자료는 속성 이 나 상태 변수, 실체변수, 마당 
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또는 자료성 원들이 다. 작용은 방법 ( we //? oc /) 또는 방법 함수 ( me 功 oc / 刀/라고 부른다. 객 
체지향기법에서는 자료와 동작을 다같이 중시하고 고찰하며 그 어느 하나도 우선시하지 
않는다. 

객체 지향파라다임 에서 자료와 작용을 동시 에 고찰해 야 한다는것 은 정 확치 않다. 계 
단식세련과 관련한 문제 (5.1) 로부터 자료가 더 중시되거나 작용이 더 중시될 때가 있다는 
것은 명백하다. 그러 나 객체지향파라다임과 관련한 개 발단계에서는 자료와 작용이 마찬 
가지 로 중요하다. 

1장과 7장에서 는 왜 객체지향파라다임 이 구조화파라다임 에 비 하여 우월한가 하는데 
대하여 고찰하였다. 이러한 리유의 기초에는 바로 잘 설계된 객체 즉 응집도가 강하고 
결합도가 약한 객체는 하나의 물리적인 실체의 측면들을 모두 모형화한다는 사실이 놓여 
있다. 이것이 실현되는 세부는 숨겨 져 있다. 즉 객체와의 유일한 통신은 객체에 보내여 
지는 통보문을 통하여 진행된다. 결국 객체는 본질적으로 잘 정의된 대면부를 가진 독립 
적 인 단위 이 다. 객 체 는 쉽 게 안전 하게 유지 정 비 될 수 있 으며 회 귀 오유가 발생 하는 기 회 도 
감소되게 된다. 더우기 8장에서 설명하는바와 같이 객체는 재리용가능하며 이러한 재리 
용가능성은 바로 계승의 특성에 의해서 강화되게 된다. 이제 객체를 리용하여 개발하는 
문제를 생각해 보자. 쏘프트웨 어에 대하여 이 러한 근본적 인 구축블로크들을 결합하여 큰 
규모의 제품을 개발하는것이 구조화파라다임을 리용하는것보다 더 안전하다. 객체는 본 
질적으로 제품의 독립적 인 구성부분이기때문에 개발의 관리는 물론 제품의 개발이 더 쉬 
워 지며 그로 인하여 오유가 더 적게 발생되는것 같다. 

객체 지향파라다임의 우월성 과 관련한 모든 측면은 한가지 문제 를 제 기한다. 즉 만일 
구조화파라다임 이 객체지향파라다임보다 나쁘다면 어째서 구조화파라다임 이 그렇게 많이 
성공할수 있었는가 하는것이다. 이것은 쏘프트웨어공학이 현실에 널리 도입되지 않았을 
때 에 구조화파라다임 이 적 용되 였 다는것 을 리해하는것 으로써 설명할수 있 다. 대 신 쏘프트 
웨어는 간단히 《작성》되 였다. 관리 자의 견지 에서 보면 가장 중요한것은 프로그람작성 
자가 많은 코드행 을 작성하는것이 였 다. 제 품의 요구사항확정 과 명 세작성(체 계분석 )에 는 
거의나 품을 들이지 않았으며 설계는 전혀 진행할수 없었다. 구성 및 수정모형 (3.1) 은 
1970년대 에 전형적 인 기법이 였다. 대부분의 개 발자들은 맨 처음에 방법상 구조화파라다 
임을 리용하였다. 이상하게도 그때 구조화기법은 쏘프트웨어산업에서 주요한 개선을 가 
져 왔다. 그러나 쏘프트웨어제품이 크기가 커짐에 따라 구조화기법이 불충분하다는것이 
인식 되 기 시 작했 고 그에 대 한 대 책 으로서 객 체 지 향파라다임 이 제 안되 였 다. 

이것 은 또 다른 질문을 제 기한다. 즉 객체지향파라다임 이 다른 모든 현재의 기 법들 
에 비 하여 더 우월하다는것을 어 떻게 확신할수 있는가? 객체지향기법 이 현재의 기 타 다 
른 기 법 보다 더 좋다고 하는데 대 하여 증명할수 있는 과학적 인 자료는 없 다. 그러한 자 
료를 얻을수도 없다. 단지 객체지향파라다임을 적용해 본 회사들의 경험을 믿는것 밖에는 
다른 길 이 없다. 어쨌든 객체지향파라다임 을 리용하는것 은 현명한 처사로 된다. 

실례로 IBM 은 객체지향기법을 리용하여 개발한 세개의 전혀 다른 프로젝트에 대하 
여 보고하였다 [ Capper , Colgate , Hunter , and James , 1994]. 거 의 모든 측면에서 객체 지 향 
파라다임은 구조화파라다임을 훨씬 릉가하였다. 특히 발견된 오유의 수가 크게 줄어 들 
었으며 예 측할수 없는 업무변경들을 초래하지 않은 개 발과 유지정 비단계 에서의 변경 요구 
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들이 훨씬 줄어 들었으며 적응 및 완전유지정비가능성이 크게 증가하였다. 그리고 비록 
앞의 네가지 측면의 개선만큼 크지는 않고 또 성능상 두렷한 차이는 없다 할지 라도 리용 
상의 측면에서도 개선이 있었다. 

객체지향파라다임 에 대 한 개 발자들의 태도를 결정 하기 위하여 150 명의 경험 있는 쏘 
프트웨 어개발자들에 대한 조사가 진행되였다 [Johnson, 2000]. 그들은 객체지향파라다임을 
리용한 96 명 의 개 발자와 여 전히 고전적 인 파라다임 을 리 용하여 쏘프트웨 어 제 품을 개 발하 
고있는 54 명의 개발자로 이루어 졌다. 객체지향파라다임그롭에 대한 긍정적인 태도가 
훨씬 더 강하였 다고 하여도 두 그룹이 모두 객체지향파라다임 이 더 우월하다고 느꼈다. 
두 그룹은 사실상 객체지향파라다임의 부족점 을 무시하였다. 

객체지향파라다임 이 많은 우월성 을 가짐 에 로 불구하고 일 련의 난관들과 문제 점 들이 
보고되였다. 제기된 문제들을 보면 흔히 개발로력과 크기와 관련되여 있다. 새로운것이 
진행되는 첫 시기에는 그이후의 경우보다 더 오랜 시간이 걸린다. 즉이러한 초기주기를 
때때 로 학습곡선 cwrve) 으로 생 각할수 있다. 그러 나 객체 지 향파라다임 이 어떤 개 
발기업체들에서 처음으로 리용될 때에는 학습곡선을 참고한다고 해도 예상했던것보다 더 
오랜 시 간이 걸린다. 이것은 구조화기 법 을 리용할 때보다 제 품의 크기 가 더 커지 는 사정 
과 관련된다. 이러한 현상은 특히 제품이 도형사용자대면부 (GUI)G0.3) 를 리용할 때 더욱 
현저하게 나타난다. 그후 사정 은 크게 개 선된다. 우선 유지 정 비비 용이 더 욱 낮아 졌고 제 
품의 전반적 인 생 명 주기비 용이 줄어 들었 다. 둘째 로 새 제 품이 개 발될 때 이 미 개 발된 
프로젝 트로부터 일부 콜라스를 재 리용하여 개 발비 용을 훨씬 더 줄일수 있었다. 이것 은 
특히 GUI 를 처 음으로 리용할 때 더 욱 의의 가 있다. 즉 GUI 에 드는 많은 비 용을 그다음 
제품개발에서 보상 받을수 있게 된다. 

계 승문제 는 해 결 하기 가 더 힘 들다. 계 승을 리용하는 중요한 리유는 어 미 콜라스와 약 
간 차이나는 새로운 부분클라스가 어미클라스 또는 계층도에 있는 임의의 다른 선조들에 
영향을 주지 않고 만들어 질수 있다는것이다. 반대로 일단 제품이 실현되여 현재의 콜라 
스에 변화가 생기면 계층도에서 그아래에 있는 모든 자손콜라스에 영향을 주게 된다. 이 
것 을 흔히 약한 기 초클라스문제 base class problem ) 라고 한다. 영 향을 받은 부분은 

적어도 다시 콤파일되여야 한다. 일부 경우에 관련이 있는 객체(영향을 받은 부분클라스 
의 실체들)의 방법들은 다시 코드작성되여야 하는데 이것은 간단치 않은 과제로 될수 있 
다. 이 문제 를 최 소화하기 위 하여 서 는 개 발과정 에 모든 클라스들을 주의 깊게 설 계하는것 
이 중요하다. 이것은 클라스의 변화로 하여 초래되는 영 향을 감소시키게 된다. 

두번째 문제 는 계 승을 그릇되 게 리용한 결 과에 의하여 초래 될 수 있 다. 명 백하게 보 
호하지 않으면 부분콜라스는 어미클라스들의 속성을 모두 계승하게 된다. 보통 부분콜라 
스는 자기 자신의 추가적 인 속성들을 가지게 된다. 결과 계층도에서 보다 낮은 준위 에 있 
는 객 체 들은 급속히 커져서 기 억 문제 를 초래 하게 된다 [Bruegge, Blythe, Jackson, and 
Shufelt, 1992]. 이것을 극복하기 위한 한가지 방도는《 가능한껏 계승을 리용하라》라는 
주장을《적 당한 곳에서 계 승을 리 용하라》하는 주장으로 바꾸어 고찰하는것 이 다. 이 밖에 
자손클라스에서 선조클라스의 속성 이 필요 없으면 그 속성은 명 백하게 배제되 여 야 한다. 

세번째 문제 는 다형성 과 동적맺 기 로부터 제 기 된다. 이 에 대 하여 서 는 7.8 에 서 론 
의하였다. 한가지 마지 막질문은 객체지향파라다임보다 더 좋은것 이 언제 인가는 있을 
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수 있겠는가 하는것이다. 지어 강력한 지지자들조차도 객체지향파라다임이 모든 쏘프 
트웨 어공학문제 에 대 한 최종적 인 대 답으로 된다고 주장하지는 않는다. 더우기 오늘날 
쏘프트웨어공학자들은 객체를 초월한 중요한 돌파구를 보고 있다. 결국 인간의 노력 
에 대해서 고찰할 때 과거의 발견이 현재 제시된것보다 더 우월하게 되는 분야는 거 
의나 없다. 객체지향파라다임이 장래의 방법론에 의하여 교체될것이라는것은 틀림 없 
다. 중요한 교훈은 현재의 지식에 기초하여 객체지향파라다임이 더 좋은것으로 교체 
될 것 이 라는것 이 다. 

요 약 

이 장은 모둘에 대 한 서 술로 시 작된 다 (7.1). 다음의 두 절은 모둘응집도와 결 합도에 
의하여 잘 설계된 모둘을 구성하는 방법 을 해 석 하고 있다 (7.2, 7.3). 특히 모둘은 강한 응 
집도와 낮은 결합도를 가져야 한다. 7.4 부터 7.6 까지에서 자료추상화와 처리절차추상화를 
비롯하여 여러가지 형태의 추상화에 대하여 서술하였다. 자료교갑화에서 (7.4) 하나의 모 
둘은 자료구조와 그 자료구조에서 수행되는 작용들을 포함한다. 추상자료형 (7.5) 은 그 류 
형의 실체 에 대 하여 실행되는 작용들과 함께 하나의 자료형으로 된다. 정보은페 (7.6) 는 
실 행세 부를 다른 모둘에 숨기 는 방법 으로 모둘을 설 계하는 내 용으로 구성 되 여 있 다. 추 
상화를 확장시켜 나가는 과정은 계승을 지원하는 추상자료형 인 클라스에 대한 서술로 종 
결된다 (7.7). 객체는 하나의 클라스의 실체이다. 다형성과 동적맺기는 7.8 의 주제이며 객 
체의 응집도와 결합도는 7.9 에서 서 술하고 있다. 이 장은 객체지향파라다임 에 대 한 론의 
로 결속한다 (7.10). 


보 충 

객체는 처음으로 문헌 [Dahl and Nygaard, 1996] 에서 서술되였다. 이 장에서 취급하고 
있 는 많은 착상들은 처 음에 파나스가 제 기 하였 다 [Pamas, 1971, 1972a, 1972b], 쏘프트웨 어 
개 발에 서 추상자료형 을 리용하는 문제 는 문헌 [Liskov and Zilles, 1974] 에 서 제 기하였 다. 
이에 대한 또 하나의 주요한 론문으로는 문헌 [Guttag, 197刀이 있다. 

응집도와 결합도에 대한 기본문헌은 문헌 [Stevens, Myers, and Constantine, 1974] 이다. 
합성/구조화설계의 착상은 객체로 확대되였다 [B 加 dey and Schach, 1997]. 

객체 에 대 한 소개 자료들은 문헌 [Meyer, 199기에서 찾아 볼수 있 다. 객체지 향프로그 
람작성 이 재 리용을 촉진시 킨 방법 들은 문헌 [Meyer, 1987, 199이에서 제시되 였다. 서 로 다 
른 류형의 계승에 대 하여서는 문헌 [Meyer, 1996b] 에서 제시되 였다. 객체지향파라다임 에 
대 한 여 러 가지 간단한 기 사들은 문헌 [El-Rewini et al„ 1995] 에 서 찾아 볼수 있다. 객 체 
지 향프로그람작성체 계，언어, 응용 (OOPSL) 에 관한 대회회 보에는 넓 은 분야의 연구론문들 
을 포함하고 있다. 그리고 회보부록에는 성과적으로 개발된 객체지향프로젝트들을 서술 




한 보고서 들이 포함되 여 있다. IBM 프로젝 트에서 객 체지향파라다임 을 성 공적 으로 리용하 
였다는데 대 하여 서 는 문헌 [Capper, Colgate, Hunter, and James, 1994] 에 서 서 술하였 다. 파 
라다임과 관련한 기 타 경험 에 대 하여서는 Communications of the ACM 1995 년 10 월호에서 
보고하였 다. 문헌 [Johnson, 2000] 에서는 객체지 향파라다임 에 대 한 립 장을 개 괄하였 다. 문 
헌 [Fayad, Tsai, and Fulghum, 1996] 에서는 객체지향파라다임 으로 어떻게 이전하였는가에 
대하여 서술하고 있다. 여기서는 또한 관리자들의 충고도 많이 서술하고 있다. 객체지향척 
도에 대 한 상세 한 설명 은 문헌 [Henderson-Sellers, 1996] 에서 주었 다. IEEE Computer 
1992년 10월호에 는《계 약에 의한 설계》에 대 하여 서술한 문헌 [Meyer, 1992a] 을 비 롯 
하여 객체에 대한 중요한 기사들이 포함되여 있다. 객체와 관련한 여러가지 기법들에 
대 하여서 는 /公公표 " o/hvare 1993년 1월호에서 찾아 볼수 있 다. 여 기서 이 분야의 주요 
용어들을 정의 한 스나이 더 (Snyder) 의 론문 [Snyder, 1993] 은 특히 가치가 있 다. 다형 성 
의 약 점 에 대 하 여 는 문 헌 [Ponder and Bush, 1994] 에 서 서 술 하 고 있 다 . 
Communications of the ACM 1995 년 1 월호에는 객체기 법 에 관한 기사들을 제시 하고 있 
다. IBM Systems Journal 1996년 2호도 이 와 마찬가지 다. 

문 제 

7.1. 당신이 익숙된 임의의 프로그람작성언어 를 선택하시 오. 7.1 에서 준 모둘성 에 
대 한 두개 의 정의 를 고찰하자. 두개 의 정의가운데서 어 느것 이 선택한 언어 로 모둘을 
구성하는것 을 직 관적 으로 리해할수 있게 하는 내 용을 포함하고 있는가? 

7.2. 다음의 모둘들에 대 한 응집도를 결 정하시 오. 

edit profit and tax record 

edit profit record and tax record 

read delivery record and check salary payments 

compute the optimal cost using Aksen’s algorithm 

measure vapor pressure and sound alarm if necessary 

7.3. 당신은 제 품개 발에 참가하는 쏘프트웨 어공학자이다. 당신의 관리 자는 당신의 그 
룹이 설계한 모둘을 가능한껏 재 리용할수 있게 하는 방법 들을 조사할것 을 요청한다. 그 
에게 무엇 이 라고 말하겠는가? 

7.4. 당신의 관리자가 당신에게 현존 모둘들을 어떻게 재리용할수 있는가를 결 
정할것 을 요청한다. 첫번째 과제 는 일 치 적 인 응집도를 가진 매 개 모둘을 기 능적 인 
응집도를 가진 개 별적 인 모둘로 분할하는것 이 다. 관리 자는 개 별적 인 모둘들이 시 험 
되 지 않았거 나 그것 들이 문서 화되 지 않았다고 지 적하였 다. 당신은 이 제 무엇 이 라고 
말 하겠는가? 
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7.5. 유지정 비 에 주는 응집도의 영향은 무엇 인가? 

7.6. 유지정 비 에 주는 결합도의 영향은 무엇 인가? 

7.7. 자료의 교갑화와 추상자료형을 정확히 구별하시오. 

7.8. 추상화와 정보은폐를 정확히 구별하시오. 

7.9. 다형 성 과 동적 맺 기 를 정 확히 구별 하시 오. 

7.10. 그림 7-23 에 있 는 설 명 문을 교원 이 지 적 한대 로 C++ 와 Java 언 어 로 바꾸시 오. 결 
과적인 모둘이 정 확하게 실행된다는것 을 확인하시 오. 

7.11. C++ 와 Java 언어 는 추상자료형 의 실현을 지 원하지 만 그것 은 정 보은폐 를 포기 하 
는 대 가로 이루어 진다는것 이 제 기되 였다. 이 주장을 론의하시 오. 

7.12. 이 장의 앞부분에 있는《 알고 싶은 문제》에서 지적한바와 같이 객체는 1966 
년에 처음으로 제기되 였다. 거의 20년이 지 나서 재발명된후에 야 객체 가 널 리 쓰이게 되 
였 다. 이 현상을 설 명할수 있 는가? 

7.13. 교원 이 구조화쏘프트웨어 제 품들을 배 포해 줄것 이 다. 정 보은페 와 추상화의 준위， 
결 합도, 응집 도의 관점 에 서 모둘을 분석하시 오. 

7.14. 교원이 객체지향쏘프트웨어제품을 배 포해 줄것 이 다. 정 보은페 와 추상화의 준위， 
결 합도, 응집 도의 관점 에 서 모둘을 분석 하시 오. 문제 7.13 의 대 답과 비 교하시 오. 

7.15. (과정 안상 목표) 부록 1에 있는 브로드렌즈지역 아동병 원제 품이 구조화파라다임 
을 리용하여 개 발되 였 다고 가정 하자. 당신 이 찾으러 고 하는 기 능적 인 응집도로 된 모둘 
의 실례 를 드시 오. 이제 제품이 객체지향파라다임 을 리용하여 개 발되 였다고 가정 하자. 당 
신이 찾으러고 하는 클라스의 실례를 드시오. 

7.16. (쏘프 트웨어공학독본) 교원은 문헌 [Johnson, 200 이의 복사본을 배포해 줄것 이다. 
왜 응답자들이 객체지향파라다임에 대한 결함이 본질적으로 무의미하다고 간주한다고 생 
각하는가? 


226 





참고문헌 


[Berry, 1978] D ， M. Berry, personal communication, 1978. 

[Binkley and Schach ， 1996] A, B, Binkley and S. R. Schach, “A Comparison of Sixteen 
Quality Metrics for Object-Oriented Design ，’，Information Processing Letters, 57 (No. 6 ， 
June 1996), pp. 271 ᅲ 75. 

[Binkley and Schach, 1997] A. B. Binkley and S. R. Schach, “Toward a Unified Approach 
to Object-Oriented Coupling，” Proceedings of the 35th Annual ACM Southeast 
Conference, Murfreesboro, TN, April 2—4, 1997, pp. 91-97. 

[Btaha, Premerlani, and Rumbaugh ， 1988] M. R. Blah a ， W. J. Premerlani, and 
J, E. Rumbaugh, “Relational Database Design Using an Object-Oriented 
Methodology，” Communications of the ACM 31 (April 1988) ， pp* 414—27* 

IBruegge, Blythe, Jackson, and Shufelt, 1992] B. Bruegge, J* Blythe, J. Jackson, and 
J. Shufelt, “Object-Oriented Modeling with OMT，’’ Proceedings of the Conference on 
Object-Oriented Programming, Languages, and Systems, OOPSLA ’92, ACM SIGPLAN 
Notices 27 (October 1992), pp. 359-376. 

[Capper, Colgate, Hunter, and James, 1994] N. R Capper ， R. J. Colgate ， J, C. Hunter，and 
M- F James, “The Impact of Object-Oriented Technology on Software Quality: Three 
Case Histories,” IBM Systems Journal 33 (No- 1 ， 1994) ， pp. 131-57. 

[Chidamber and Kemerer, 1994] S. R ‘ Chtdamber and C. F. Kemerer ， “A Metrics Suite for 
Object Oriented Design, 1 * IEEE Transactions on Software Engineering 20 (June 1994), 
pp. 476-93. 

[Dahl and Nygaard, 1966] 分 -J ， Dahl and K. Nygaard, “SIMULA—An ALGOL-Based 
Simulation Language,” Communications of the ACM 9 (September 1966), pp, 671-78. 

[El-Rewini et aL, 1995] H. El-Rewini, S. Hamilton, Y.-P. Shan, R, Earle, 

S. McGaughey, A. Helal, R. Badrachalam, A. Chien, A* Grimshaw, B. Lee, 

A, Wade, D. Morse ， A. Elmagramid, E. Pitoura, R, Binder, and P. Wegner, 
“Object Technology，，’ IEEE Computer 28 (October 1995), pp. 58-72. 

[Fayad, Tsai, and Fulghum, 1996] M. E, Fayad, W.-T. Tsai, and M* L* Fulghum, 

“Transition to Object-Oriented Software Development/' Communications of the ACM 
39 (February 1 996 》， pp. 108-21 * 

[Flanagan and Loukides, 1997] D. Flanagan and M. Loukides, Java in a Nutshell: A 
Desktop Quick Reference ， 2nd ed„ O’Reilly and Associates ， Sebastopol, CA ， 1997. 

[Gerald and Wheatley, 1999] C, F. Gerald and P* O. Wheatley, Applied Numerical 
Analysis, 6th ed., Addison-Wes ley, Reading, MA, 1999. 

[Goldberg and Robson, 1989] A. Goldberg and D. Robson, Smalltalk-80: The Language, 
Addison-Wesley, Reading, MA, 1989. 

[Guttag, 1977] J. Guttag, “Abstract Data Types and the Development of Data Structures，” 
Communications of the ACM 20 (June 1977), pp. 396-404. 

[Henderson-Sellcrs, 1996] B. Henderson-Sellers, Object-Oriented Metrics: Measures of 
Complexity, Prentice Hall, Upper Saddle River, NJ, 1996. 

[ISO/IEC 8652, 1995] “Programming Language Ada: Language and Standard Libraries，’’ 
ISO/IEC 8652, International Organization for Standardization, International 
Electrotechnical Commission ， Geneva ， 1995. 

[Johnson ， 2000] R. A* Johnson ， “The Ups and Downs of Object-Oriented System 
Development/* Communications of the ACM 43 (October 2000), pp. 69-73. 

[Knuth, 1974] D. E, Knuth, “Structured Prog 的 mming with go to Statements,” ACM 
Computing Surveys 6 (December 1974), pp. 261-301. 

[Liskov and Zilles, 1974] B, Liskov and S, Zilles, “Programming with Abstract Data 
Types,” ACM SIGPLAN Notices 9 (April 1974), pp. 50-59. 

[Meyer ， 1986] B, Meyer, “Genericity versus Inheritance，” Proceedings of the Conference on 


227 






Object-Oriented Programming Systems，Languages and Applications, ACM SIGPLAN 
Notices 21 (November 1986), pp. 391^05. 

[Meyer ， 1990] B. Meyer, “Lessons from the Design of the Eiffel Libraries，” 
Communications of the ACM 33 (September 1990) ， pp. 68-88* 

[Meyer, 1992a] B. Meyer, “Applying 4 Design by Contract'” IEEE Computer 25 
(October 1992), pp. 40-51. 

[Meyer, 1992b] B. Meyer, Eiffel: The Language ， Prentice Hall ， New York, 1992. 

[Meyer, 1996b] B. Meyer, “The Many Faces of Inheritance: A Taxonomy of Taxonomy,” 
IEEE Computer 29 (May 1996), pp. 105-8* 

(Meyer, 1997J B. Meyer, Object-Oriented Software Construction, 2nd ed.，Prentice Hall, 
Upper Saddle River, NJ, 1997. 

[Myers ， 1978b] G. J. Myers, Composite/Structured Design, Van Nostrand Reinhold, 

New York, 1978. 

[Parnas, 1971 ] D. L. Parnas, ^Information Distribution Aspects of Design Methodology,” 
Proceedings of the IF IP Congress ， Ljubljana, Yugoslavia, 1971, pp, 339 니 44 ， 

[Parnas, 1972a] D, L. Parnas, “A Technique for Software Module Specification with 
Examples, Communications of the ACM 15 (May 1972), pp. 330-36* 

[Parnas, 1972b] D. L. Parnas, “On the Criteria to Be Used in Decomposing Systems into 
Modules，” Communications of the ACM 15 (December 1972), pp. 1053-58, 

lPonder and Bush ， 1994] C. Ponder and B. Bush, "Polymorphism Considered Harmful,” 
ACM SIGSOFTSoftware Engineering Notes 19 (April 1994), pp. 35—38. 

[Schach, 1996] S. R. Schach, “The Cohesion and Coupling of Objects，” Journal of 
Object-Oriented Programming 8 (January 1996), pp. 48-50. 

[Schach and Stevens-Guille, 1979J S. R. Schach and P. D, Stevens-Guille, “Two Aspects 
of Computer-Aided Design，’’ Transactions of the Royal Society of South Africa 44 
(Part 1 ， 1979) ， 123-26. 

[Shneiderman and Mayer, 1975] B, Shneiderman and R. Mayer, “Towards a Cognitive 
Model of Programmer Behavior, M Technical Report TR-37, Indiana University, 
Bloomington, 1975. 

ISnyder, 1993] A- Snyder, “The Essence of Objects: Concepts and Terms；* IEEE Software 
10 (January 1993), pp. 31-42, 

[Stevens, Myers, and Constantine, 1974] W. P. Stevens, G. J. Myers, and 

L, L, Constantine, “Structured Design；' IBM Systems Journal 13 (No* 2, 1974), 
pp. 115-39* 

[Stroustrup ， 1991] B. Stroustrup, The C++ Programming Language, 2nd ed., 
Addison-Wesley, Reading, MA, 1991* 

[Yourdon and Constantine, 1979] E. Yourdon and L. L. Constantine ， Structured Design: 
Fundamentals of a Discipline of Computer Program and Systems Design, Prentice Hall, 
Englewood Cliffs ， NJ, 1979. 


228 





제 8 장. 재리용성，이식성，호상조작성ᅱ 


수레 바퀴를 재 발명 한것 이 형 법상 위 반이 라면 많은 쏘프트웨 어전문가들은 감옥에서 
옥고를 치르게 될것이다. 실례로 수만개(수십만개는 아니다)의 COBOL 로임지불계산프로 
그람이 있는데 이것들은 모두 본질적으로 같은 일을 수행한다. 세계적으로 요구되는것은 
바로 여 러 가지 하드웨 어 에서 동작할수 있고 잘 가공된 하나의 로임지불계산프로그람이다. 
필요하다면 개 별적 인 기 업 체의 특정한 요구들에 응하는것 이 다. 그러 나 이전에 개 발된 로 
임 지불계산프로그람대 신에 자체 의 로임지 불계 산프로그람을 령상태 에서 개 발하고 있다. 

이 장에 서 는 왜 쏘프트웨 어공학자들이 계 속《 수레 바퀴》를 재 발명 하고 있는가 그리 
고 재 리용할수 있는 구성 요소들을 리용하여 개 발한 이 식 가능한 쏘프트웨어 를 완성 하기 
위하여 무엇을 할수 있는가 하는것을 고찰한다. 우선 이 식성과 재 리용성 을 구별하는것부 
터 론의 를 진행한다. 


8.1. 재리용의 개념 

령 상태 에 서 제 품을 다시 코드작성 하는것 보다 다른 콤파일 러 와 하드웨 어 조작체 계 상태 
에서 동작할수 있도륵 전반적인 제품을 수정하는것이 더 쉽다고 하면 제품은 이식가능하 
다. 이와 대비적으로 재리용은 서로 다른 기능을 가진 서로 다른 제품개발을 촉진시키기 
위하여 하나의 제품에 들어 있는 구성부분들을 리용하는것을 의미한다. 재리용가능한 구 
성부분은 반드시 하나의 모둘이나 코드토막일 필요는 없다. 즉 그것은 하나의 설계일수 
도 있고 지도서의 한 부분일수도 있으며 하나의 시험 자료모임도 될수 있고 혹은 기 간이 
나 비용타산일수도 있다. 

재리용에는 두가지 류형이 있는데 하나는 우연적인 재리용이고 다른 하나는 계획적 
인 재리용이다. 새로운 제품을 개발하고 개발자가 이미 개발된 제품의 어느 한 구성부분 
을 새로운 제품에서 리용할수 있다면 이것을 우연적인 재리용 또는 기회적인 재리용이라 
고 한다. 쏘프트웨어의 구성부분을 리용하는것을 계획적인 재리용 혹長 체계적인 재리용 
이라고 한다. 우연적인 재리용에 비하여 계획적인 재리용의 잠재적인 우점의 하나는 앞 
으로 리용하기 위하여 특별히 개발한 구성부분들이 재리용하기 더 쉽고 안전하다는것이 
다. 즉 이러한 구성부분은 보통 로바스트적이며 잘 문서화되여 있고 철저히 시험된다. 이 
밖에 그 구성부분들을 유지정비하기 더 쉽도록 유일한 형태로 서술해 준다. 다른 한 측 
면은 회 사안에서 계획적 인 재 리용을 실현하는데 는 비용이 든다는것 이 다. 쏘프트웨 어구성 
부분에 대하여 명세를 작성하고 설계, 실현，시험，문서작성하는데는 시간이 걸린다. 그러 
나 이 러한 구성부분을 재 리 용함으로써 잠재적으로 재 리용가능한 구성부분을 개 발하는데 


앞에서 언급한바와 같이 이 장의 자료는 제 2 편에서 다시 고찰한다 . 
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투자되는 비용이 보상된다는 담보는 없다. 

처음에 콤퓨터가 개발되였을 때는 아무것도 재리용하지 못하였다. 매번 제품이 개발 
될 때 마다 곱하기 부분프로그람과 입 출력 프로그람，시 누스，코시 누스를 계 산하는 부분프로 
그람과 같은 항목들을 령상태에서 개발하였다. 그러나 인차 이것은 토력랑비가 많다는것 
을 깨 닫고 부분프로그람서고가 구축되 였 다. 그다음 프로그람작성 자는 요구될 때 마다 2차 
뿌리나 시누스함수를 간단히 불러 낼수었었다. 이러한 부분프로그람서고는 더욱더 갱 
신되 고 실시 간지 원부분프로그람으로 개 발되 였 다. 따라서 프로그람작성 자가 C ++ 나 Java 
방법 을 호출할 때 정 확히 관리하거 나 인수를 넘 길수 있도록 코드를 작성할 필요가 없게 
되 였 다. 즉 적 당한 실시 간 지 원부분프로그람을 호출함으로써 자동적 으로 관리하게 되 였 
다. 부분프로그람서고에 대 한 개 념은 SPSS [ Norusis , 2000] 와 같은 대 규모통계서고와 
NAG [ Phillips , 1986] 와 같은 수자처 리분석서고들로 확장되 였다. 클라스서 고들은 객체지향 
언어 를 리용하는데 서 중요한 역 할을 논다. Eiffel 언어환경 은 7개 의 클라스서 고들을 병 합하 
였다 [ Meyer , 1990]. Smalltalk 가 어느 정도 성공한것은 Smalltalk 서고안에 아주 다양한 항목 
들이 있었기때문이다. 두 실례에서 모두 클라스서고를 찾아 보는것을 방조하는 CASE 도 
구는 큰 도움을 주고 있 다. C ++ 와 관련하여 아주 많은 서 로 다른 서 고들이 리용되 였 다. 
그 하나의 실 례 로는 C ++ 표준서 고 ( STL ) 가 있 다 [Musser and Saini , 1996]. 

응용프로그람작성대 면부 ( API ) 는 보통 프로그람작성 을 촉진시키 는 조작체 계호출들의 
모임으로 된다. 실례로 Win 32 는 원도우즈 2( X )0 과 윈도우즈 NT 와 같은 마이크로쏘프트조 
작체 계 를 위한 API 이 며 마킨토쉬 도구통은 마킨토쉬 조작체 계 MacOS 를 위한 API 이 다. 비 
록 API 가 보통 조작체 계호출들의 모임 으로 실 현된 다고 하여 도 API 를 구성하는 부분프로 
그람은 프로그람작성 자에 게 는 부분프로그람서고로 간주될수 있 다. 실례 로 Java 응용프로그 
람작성대면부는 많은 프로그람묶음(서고)으로 구성되 여 있다. 

쏘프트웨어제품의 품질 이 아무리 높다고 하여 도 경쟁대 상으로 되는 제 품이 2년동 
안에 배포될수 있다고 할 때 시장에 나가는데 4년 걸린다고 하면 그것은 팔지 못하게 
될것 이 다. 개 발과정 이 길게 되면 시 장경제 에서는 위 험한것 으로 된다. 《 좋은》제 품을 
구성하는것 과 관련한 모든 다른 기 준은 그 제 품이 시 간적 으로 경 쟁할수 없다면 관계 
없 다. 제 품을 처 음으로 출품하여 실패한 회 사들에 대 해서 는 쏘프트웨 어재 리용기술이 
유혹적 인 기 술로 되 고 있다. 결 국 현존구성 부분이 재 리용되 면 그 구성 부분을 다시 설 
계 하고 실현하며 시 험 하고 문서 작성할 필요가 없게 된다. 중요한것은 쏘프트웨어제품 
개발에서 평균 약 10%만이 원래의 목적을 실현하는데 리용되게 된다는것이다 [ Jones , 
1984]. 리론적으로 제품의 다른 나머지 85%는 표준화되여 장래의 제품개발에 재리용 
될것이다. 

85%라는것 은 리 론적 으로 볼 때 재 리용률에 서 상한값으로 된 다. 8.3 에 서 보여 준 
바와 같이 실천에서는 재리용률이 40%정도로 된다. 이로부터 다음의 질문을 제기된다. 
만일 재 리용률이 실 천적 으로 이 정 도의 값을 가지 게 되 고 재 리용이 결코 새 로운 착상 
이 아니 라면 왜 그렇 게 적은 기 업체들에서 개 발과정 을 단축하기 위하여 재 리용을 진 
행 하는가? 
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8.2. 재리용의 장애 

재 리용하는데는 많은 장애들이 있게 된다. 즉 

1. 많은 쏘프트웨어전문가들은 다른 전문가에 의해서 작성된 부분프로그람을 재리용 
하는것보다도 그 부분프로그람을 처음부터 다시 작성하려고 한다. 그것은 그들자 
신이 작성하지 않으면 부분프로그람이 좋다고 생각하지 않는다는것을 의미한다. 
이것은 다른 말로 NIH (« 아 invented here , 여 기서 발명 하지 않은)증후군으로 알려 
져 있다 [ Griss ，1993]. NIH 는 관리상문제이며 관리자측이 문제를 깨닫고 있으면 그 
문제는 재리용을 촉진시키기 위하여 재정상 방조를 제공함으로써 해결될수 있게 
된 다. 

2. 많은 개 발자들은 부분프로그람이 제 품에 오유를 발생 시키지 않는다는것 이 확실하 
면 그러한 부분프로그람을 선뜻 재 리용하려 고 할것 이 다. 쏘프트웨어 의 품질과 관 
련하여 이러한 태도를 취하는것은 아주 당연한다. 결국 매 쏘프트웨어전문가들은 
다른 사람이 작성한 쏘프트웨어 에 오유가 있는것 으로 본다. 여 기서 문제 해 결방안 
은 그들이 재리용을 진행하기전에 철저히 시험을 진행하며 가능한껏 재리용부분 
프로그람에 복종하는것 이 다. 

3. 큰 기업체들에서는 수십만개나 되는 잠재적으로 리용가능한 구성부분들을 가지고 
있을수 있다. 이러한 구성부분들을 후에 다시 효과적으로 찾아 보자면 그것들을 
어떻게 보관해야 하겠는가? 실례로 재리용가능한 구성부분자료기지는 2만개나 되 
는 항목들로 구성되고 여기서 정렬부분프로그람만 해도 125 개나 될수 있다. 자료 
기지는 새 제품을 개발하는 개발자들로 하여금 125 개의 정렬부분프로그람가운데 
서 어 느것 이 새 제 품에 알맞는 부분프로그람인 가를 인 차 결정할수 있도륵 구성 되 
여 야 한다. 보관과 검 색문제 를 해 결 하는것 은 아주 다양한 문제 해 결을 제 기하는 기 
술적 인 문제 로 된다 [Meyer, 1987 or Prieto-Diaz, 1991]. 

4. 재 리 용은 비 용이 든다. 트라즈 ( Tracz ) 는 다음의 세 가지 측면에 서 비 용이 든다고 
언급하였 다. 즉 재 리용가능한것 을 만드는데 드는 비 용과 그것 을 재 리용하는데 드 
는 비 용, 재 리용과정 을 정 의 하고 실현하는데 드는 비 용이 있 다 [ Tracz , 1994]. 그는 
재리용가능한 구성부분을 만드는데는 적어도 60%까지의 비용이 든다고 타산하였 
다. 일부 기업체들에서는 200%까지 비용이 든다고 보았고 지어는 480%까지도 비 
용이 들게 된다고 보고하였으며 반면에 8.5.3 에서 보고한 어느 한 훌레트-패카드 
회 사의 재 리용프로젝 트에 서 는 재 리용가능한 구성 부분들을 만들어 내 는데 11%정 
도비용이 들었 다고 보고하였 다 [ Lim ，1994]. 

우에서 언급한 네가지 장애문제는 원리적으로 극복할수 있다. 

다섯번째 문제 는 쏘프트웨 어계 약과 관련되 는 법 률상의 문제 로서 보다 더 문제 성 이 
있 다. 의 뢰 자와 쏘프트웨 어개 발기 업 체사이 에 작성한 계 약에 따르면 쏘프트웨어 제품은 의 
뢰자에 게 속한다. 따라서 쏘프트웨 어개 발자들이 어 느 한 의 뢰 자의 제 품에 있 는 구성 부분 
을 다른 의 뢰 자의 새 로운 제 품에 재 리용하면 이 것은 본질적 으로 첫 번째 의 뢰 자의 저 작권 
에 대한 위반으로 된다. 개발자와 의뢰자가 같은 기업체의 성원들일 때는 내부의 쏘프트 
웨어에 대하여 이런 문제가 제기되지 않는다. 여섯번째 장애는 상업적인 규격 ( COTS ) 구 
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가 주어 지 게 되 는 경 우가 있 게 된 다. 그리하여 COTS 구성 부분을 재 리용한 쏘프 
확장하고 수정 하는데 서 제 한을 받는다. 


알:2 싶 e 寒제 

WWW 는《도시 신화知必 myths) > 측 명백히 사실인 이야기들의 주요원천으. 
데 이러한 이야기들은 암만해도 그 출처를 철저히 조사할수 없다. 이와 같이 한가. 
신화는 코드의 재 리용과 관련되 여 있 다. 

이 이야기% 오스트랄리아공군이 직승기전투훈련을 위하여 가상현실감이 있_ 
의기 를 설치하는것을 내 용으로 하고 있다. 가능한껏 현실성 있게 대본을 만들기 
프로그람작성 자들은 자세한 풍경 과 그리 고(북부지 방에 있는)，캉가루무리 를 포함 
결국 직승기에 놀란 캉가루무리에 의하여 일어 난 먼지는 적들이 그. 직승기의 위. 
견할수 있게 하였다. 

프로그람작성자는 캉가루의 움직 임과 직승기에 대한 캉가루들의 반응을 모두 
할데 대 한 지시 를 받았다. 시 간을 절 약하기 위하여 프로그람작성 자들은 원래 직#: 
호하에 공격하는 보병 들의 동작을 모의하는데 리 용하였 던 코드를 재 리 용하였 다. 
다만 두개 의 변경 을 진행하였 다. 즉 그들은 그림 을 병 사들로부터 캉가루로 바꾸 S 
리고 그림의 이동속도를 빠르게 하였다. 

어느 날 오스트랄리아비행사들의 한 그룹은 방문하여 온 미군비행사들에게 이 
를 가지 고 진행하는 훈련동작들을 보여 주기 로 하였 다. 모의기 는 가상적 인 캉가. 
윙 날아 다녔다. 기대했던바대로 캉가루들이 홀어 졌다가 언덕너머에서 다시 나타 
기 에 스링 거미싸일 을 발사하였 다. 프로그람작성 자들은 가상적엔 보병 들의 동작을 
할 때 그 코드부분을 제거해 버리는것을 잊어 버렸다. 

그러 나 모험 집 에서 서 술한바와 같이 이 이 야기 는 전혀 도시신화가 아니 라 훨삭 
제적 인것 같다 [Green, 2000]. 오스트랄리 아국방과학 및 기술기 업체 에 있는 모의상 S 
책 임 자인 아네 마리 에 그리소고노 (Anne-Marie Grisogono) 박사는 1999년 5월 6일 오스 
아 캔 베 라에서 있은 회 견에 서 이 이 야기 를 말해 주었 다. 비 록 모의기 가 가능한껏 
있게 설계되였다(공중사진을 나타내도록 지어 200만그루이상되는 나무를 포함시! 
하여 도 캉가루는 장난삼아 포함시 켰 다. 프로그람작성 자들은 직승기 가 도착하였 p 
캉가루가 발견 할수 있도록 실 지 스팅 거 미 싸일발사과정 을 재 리 용하였 으며 직 승기 : 
하면 정 확히 캉가루가 무서 워 서 도망치 도록 하기 위하여 캉가루가 뒤 로 물러 다- 
작을 설 정하였 다. 그러 나 쏘프트웨 어 개발림 이 연구소에 서 그 모의기 를 시 험 하였 ^ 
들은 무기와 불 불는 동작을 다 제거해 버리는것을 잊어 버렸다. 또한 그들은 무 
의된 형래로 리용된다는것을 서술하지 않았으며 따라서 캉가루는 직승기에 발사 t 
러가지 색갈의 # 고무공들이 나타나는 암묵적 인 무기 를 사용하였 다. 

그리 소고노는 캉가루가 측시 에 무장해제되 였으므로 이제 는 오스트랄리 아상공. 




그러 므로 법 률상의 문제 나 그리 고 COTS 구성 부분을 리용하는 문제 외 에 는 쏘프트웨 어 
기 업체 안에서 재 리 용과 관련하여 다른 주요한 장애 가 없다(우의 《 알고 싶은 문제》를 
보시 오.). 


8. 3. 재리용의 실례연구 

다음의 여섯가지 실례연구는 재리용이 실천에서 어떻게 성과를 거두었는가를 보 
여 주고 있다. 그것 은 1976년부터 2000년까지 25년동안에 걸 쳐 진행 된것 들이 다. 

8. 3. 1. 레이손미싸일체계관리국 

1976년에 레이손미싸일체계관리국은 설계와 코드에 대하여 계획적인 재리용이 가능 
한가 하는 연구를 진행 하였 다 [Lanergan and Grasso , 1984]. 리 용중에 있는 5,000개 가 넘 는 
제품들을 분석하고 분류하였다. 연구자들은 업무응용제품에서 다만 6개의 기본적 인 작용 
들만이 진행될수 있다는것 을 결정하였 다. 결과 40%부터 60%사이의 업무응용제품에 대 하 
여 설계 와 모둘이 표준화되 고 재 리용되 였 다. 기 본적 인 작용으로서 는 자료의 정돈, 자료의 
편집 또는 조작，자료결합，자료의 뒤집기, 자료갱신, 자료에 대한 보고서작성이 있다. 그 
다음 6년동안은 가능한껏 설계 와 코드를 재 리용하기 위하여 노력하였 다. 

레 이 손연구는 두가지 방법 으로 재 리용을 진행하였 다. 연구자들은 이 두가지 방법 을 
기 능모둘 woc / wfe ) 과 COBOL 프로그람론리 구조라고 명 명 하였 다. 레 이 손학술용어 
에서 기 능모둘은 편집 부분프로그람이 나 자료기지처 리절차부분호출，세 금계 산부분프로그 
탐, 접 수된 계 산서 를 위한 날자시 효계 산부분프로그람과 같이 특정한 목적 으로 설계 되 고 
코드작성 된 COBOL 코드토막이 다. 3,200여개 의 재 리용가능한 모둘들가운데 서 60%의 재 리 
용코드가 응용프로그람들에 적용되였다. 기능모둘은 주의깊게 설계되고 시험되며 문서작 
성된다. 이러한 기능모둘들을 리용한 제품들은 보다 더 믿음성 있고 전체적인 제품에 대 
하여 요구되는 시험 을 더 적 게 진행할수 있다는것 을 알수 있었다. 

모둘은 표준적 인 복사서고에 보관되 며 복사하여 엄 을수 있 다. 즉 코드는 응용프로그 
람제 품에서 물러적 으로 존재하는것 이 아니 라 를파일할 때 COBOL 를파일 러 에 의해서 제 
품에 포함되게 된다. 이 방식은 C 언어나 C ++ 언어에서 # include 와 류사하다. 그러므로 결 
과적인 제 품의 원천코드는 복사된 코드가 물리 적 으로 존재하면 보다 더 짧아 지 게 된다. 
결과 유지정비는 보다 더 쉬워 진다. 레이손연구자들은 또한 COBOL 프로그람론리구조라 
는것 을 리용하였다. 이 것은 완성된 제 품에 대 하여 더 욱 보충되 여 야 할 기 본틀거 리 이 다. 
론리구조의 한가지 실례 는 갱 신론리구조이 다. 이것 은 5丄1에 있는 실례연구에서 와 같이 
련속적 으로 갱 신을 진행하는데 리 용된다. 오유조종은 순차적 인 검사과정이므로 갱 신론리 
구조에 속한다. 론리구조는 길이로 22개의 단락이다(단락은 COBOL 프로그람의 단위 이 다). 
get _ transaction , print _ page _ headings , print_con 仕 ol_totals 와 같은 기 능모둘을 리 용하여 많은 
단락들이 채워 지게 된다. 그림 8-1 에서는 기능모둘로 채워 놓은 단락들로 이루어 진 
COBOL 프로그람론리구조의 기본틀거 리에 대하여 기호적으로 표현하고 있다. 
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□ COBOL 프로그람 
론려 구조 

I I 기^모둘 


그림 8-1. 테 이손미싸일체계관리국 재 리용기구에 대한 기호적 인 표현 

이러한 제품에 대한 기본틀거리가 이미 만들어 져 있기때문에 제품의 설계와 코드작 
성은 보다 더 쉽고 빨리 진행할수 있게 된다. 여기서 필요한것은 상세하게 모두 채워 놓 
는것이다. 파일의 끝조건과 갈은 오유를 범하기 쉬운 령역은 이미 시험되였다. 사실상 전 
체적인 시험도 더 쉬워 진다. 그러나 레이손연구자들은 주요한 우점이 바로 수정이나 확 
장에 있 다고 보았다. 일 단 유지 정 비프로그람작성 자가 관련 있는 론리구조에 익 숙하면 그 
는 거의나 원래의 개발림성원처럼 된다. 

1983년까지 론리구조는 새 로운 제 품을 개 발하는데 5,500번 이상 리용되 였 다. 코드의 
약 60%는 기 능모둘 즉 재 리용가능한 코드로 구성되 였다. 이것 은 설계, 코드작성，모둘 
시험，문서작성시간이 60%까지 감소되며 쏘프트웨어제품개발의 생산성에 있어서 50% 
까지 증가된다는것을 의미한다. 그러나 레이손에 있어서 이러한기법의 실제적인 리득 
은 규형의 일치로 인한 가독성과 피해가능성 이 유지정 비의 비용을 60-80%사이 에서 줄 
일것이라는 기대에 있었다. 유감스럽게도 레이손은 필요한 유지정비자료를 엄을수있 
기 전에 자기 일 을 마쳤다. 

재 리용은 업 무자료처 리응용프로그람들에 서 만 적 용될 수 있는것 같다. 그러 나 두번째 
실 례연구 즉 토시바쏘프트웨어 에서 보여 준바와 같이 그렇 지 는 않다. 

8. 3. 2. 토시바쏘프트웨어제작소 

1977년에 토시바회 사는 도교토시바휴츄공장에 서 휴츄쏘프트제 작을 시 작하였 다. 휴츄 
공장에서는 전력망, 원자력발전소, 자동차제작 등 여러 부분들에 필요한 산업공정조종체 
계 를 생 산하고 있 으며 쏘프트웨어 제작소에 서는 그러한 체 계 들에 서 요구되 는 공정 조종콤 
퓨터 들을 위 한 응용쏘프트웨 어 를 개 발하고 있 다 [ Matsumoto , 1984, 198刀. 
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1985 년까지 쏘프트웨어제작소에는 모두 2, 300명의 기술 및 관리성원들이 종사하고 
있 었다. 코드의 약 60%는 실 시 간부분프로그람에 의하여 담보되 는 FORTRAN 언 어 로 작성 
되 여 있다. 그리 고 20%는 아쌤 블리어 와 같은 언 어 들로 작성 되 고 기 타 나머 지 는 문제 에 
따르는 해 당한 언어 로 작성되 였 다. 쏘프트웨어 제작소는 코드의 행 수로 생 산성 을 측정한 
다. FORTRAN 언 어 로 1,000행 되 는 코드를 작성 하는데 드는 품은 아쎔 블리 어 로 1,000행 되 
는 코드를 작성하는데 드는 품과 차이 나기 때 문에 생 산성 평 가를 위한 단위 를 등가인 아쎔 
블리 어원천코드행수 ( EASL ) 로 설정하였 다 [ Jones , 1996]. 여 기서 일 반적 으로 고급언어 로 작 
성 된 코드 한행 은 아쌤 블리 어 에 서 는 4개 행 에 해 당된 다고 보고 변 화비 례 결 수를 설 정 하였 
다. 이러한 측정방법을 리용하여 1985년에 쏘프트웨어제작소에서 개발된 제품은 720만 
EASL 이 였다. 제 품은 크기 가 1백 만 EASL 부터 2천 1백 만 EASL 까지 있었는데 평 균크기는 4 
백 만 EASL 이 였 다. 

쏘프트웨어 는 폭포모형 을 리용하여 개 발되 였 으며 매 개 발단계 의 마감에 서 자세한 심 
사와 검 토를 진행하였 다. EASL 로 측정한 생 산성 은 쏘프트웨 어개 발을 추동하였 다. 생 산성 
은 프로젝 트전반과 개 별적 인 프로젝 트의 기 초우에서 관리되 였 다. 제 작소적 으로 매 해 생 
산성 은 8〜9%까지 올라 갔다. 성 능평 가에서 측정하여 야 할 항목중의 하나는 개 별적 인 
오유률이다. 실례 로 프로그람작성 자의 경우에 1，000 EASL 당 오유수는 숙련과 경 험시 간에 
따라 감소되리라고 본다. 품질은 제작소에서 가장 중요한 측면으로 되고 있으며 심사와 
검사, 품질토의를 포함한 많은 다른 기구를 통하여 품질이 보장되게 된다. 

마쯔모도 ( Matsumoto ) 는 현존 쏘프트웨 어 를 재 리 용(우연적 인 재 리 용)함으로써 생 산성 
과 품질에서 모두 개선이 있었다고 하였다 [ Matsumoto , 1987]. 이러한 재리 용가능한 쏘프 
트웨어 는 모둘뿐아니 라 설계，명세서，계 약, 지도서와 갈은 모든 종류의 문서 들을 포함하 
게 된다. 위원회는 어느 구성부분을 재리용가능한 구성부분자료기지에 넣어 주는가를 결 
정한다. 여 기서 자료기지 에는 이후의 검색을 위하여 색 인을 하였다. 자료기지 에 있는 매 
구성 부분들에 대 하여 재 리 용률을 통계 낸 다. 문서 작성 에 대 한 재 리 용률은 재 리 용된 문서 
의 페 지 수를 총 페 지 수로 나눈것 인데 1985년에 문서 작성 의 재 리용률은 32%였다. 설계단 
계 에서는 재 리용률이 33%였고 실현단계에서 는 코드의 48%가 재 리용되 였다. 더우기 재 리 
용된 쏘프트웨 어구성 부분의 크기 에 대 하여 통계 를 냈는데 약 55%는 크기 가 1 K -10 K 
EASL 였으며 36%는 10 K -100 KEASL 범위에 있었다. 

NASA 에 서 개 발한 25개 쏘프트웨어 제품에 대 한 통계 는 다음 부분에 서 고찰하도록 
한다. 


8. 3. 3. NASA 쏘프트웨어 

쎌 비 ( Selby ) 는 무인우주비 행 선조종을 위한 쏘프트웨 어 를 생 산하는 NASA 쏘프트웨 어 
제 품생 산그룹에 서 진행한 쏘프트웨어 의 우연적 인 재 리용에 대 하여 서 술하였 다 [ Selby , 
1989]. 모두 25개 의 쏘프트웨어 들에 대 하여 조사를 진행하였 다. 그 쏘프트웨어 제품들은 
크기가 원천코드로 3,000~11，200행 되였다. 7,188개의 구성부분모둘에 대하여 네부류로 분 
류하였 다. 그를 1은 변화가 없 이 리 용된 모둘들이다. 그룹 2는 약간 수정한 모둘들이다. 
즉 코드에 대 하여 25%이 하 변화시 킨것 들이 다. 그롭 3은 25%이 상의 코드를 수정한 모둘 
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들로 구성 된다. 그룹 4는 처 음부터 개 발한 모둘들이다. 

표본 실례 에 있는 2,954 개 의 전체 FORTRAN 모둘들이 자세 히 연구되 였다. 구체 적 으 
로 말하면 28% 는 그룹 1 에, 10% 는 그룹 2 에, 7% 가 그룹 3 에 속한다. 일반적 으로 재 리용 
된 모둘들은 작고 잘 문서 화되 여 있 다. 이 런 모둘들은 간단한 대 면부와 약간한 입 출력처 
리 를 진행하는것 들이 며(그림 7-7 에 서 와 같이) 모둘호상접 속도에서 말단마디 쪽에 있 다. 

이 결과들은 사실 놀라운것은 아니다. 작고 잘 문서화된 모둘들은 문서화가 힘든 큰 
모둘들에 비 하여 리해 하기 가 더 쉬 우며 따라서 재 리용되 기 가 더 쉽다. 더 우기 큰 모둘들 
은 특정한 작용보다도 많은 다른 작용들을 수행할수 있 다. 따라서 보다 작은 모둘들보다 
더 적 게 재 리용될 수 있 다. 복잡한 대 면부는 인수들이 아주 많다는것 을 암시하는데 이 것 
은 모둘의 재 리용률을 떨어 뜨리는 경 향이 있다. 입 출력처 리는 어 느 정도 응용프로그람 
에 특정하며 더 적 게 재 리용될 수 있 다. 마지 막으로 모둘호상접 속도의 말단에 있는 모둘 
들을 그우에 있는 모둘들과 비 교해 보면 말단모둘들은 보다 더 특정한 과제 를 수행할수 
있으며 반면에 웃쪽에 있는 모둘들은 결심에 따른다고 본다(이에 대하여 15 丄 1 에서 깊이 
론의 되 였 다.). 결과 말단모둘은 그밖의 모둘보다 더 재 리용가능하게 된 다. 

쎌비의 결과를 고찰하는데서 건설적인 방법은 모둘들을 앞으로의 제품개발에서 재리 
용할수 있다는것 이 다. 관리 자는 특정한 설계객체는 간단한 대 면부를 가진 작은 모둘이 여 
야 한다는것 을 담보하여 야 한다. 입출력처 리는 몇개의 모둘에 국한되 여 있다. 모든 모둘 
올은 철 저 히 문서 화되 여 야 한다. 

NASA 그룹과 휴츄쏘프트웨어 제작소사이 에 는 중요한 차이 가 있다. 특히 쏘프트웨 
어 를 재 리 용할데 대 한 결심 은 NASA 쏘프트웨 어 개 발자들의 독단적 인 선택 이 였다. 즉 
그 어떤 관리상 지시 가 없었다. NASA 성 원들은 재 리용이 가치 있는 쏘프트웨 어공학기 
술이 라는것 을 믿 고 있었기때 문에 간단히 쏘프트웨어 를 재 리용하였 다. 이 밖에 재 리 용 
과정을 방조하는 쏘프트웨어도구는 없다. 이러한 상황은 휴류공장에서 진행하는 재리 
용지향의 관리와 명백하게 대조되며 거기서는 정교한 쏘프트웨어구성부분 검색기구 
를 리용하게 된다. 이럼에도 불구하고 놀랍게도 NASA 에서는 높은 비률로 재리용을 
진 행 하고 있다. 

네 번째 실 례 연구는 재 리 용에 대 한 관리 계 약의 효과를 명 백 히 하고 있 다. 

8. 3. 4. GTE 자료봉사기구 

우연적 인 재 리용계 획 을 성 공적 으로 실 현한것 은 GTE 자료봉사였 다 [ Prieto - Dkz ，1991]. 
NASA 실례연구와는 달리 GTE 계 획 에 있어서 중요한 측면은 원천코드모둘의 재 리 용에 
대 한 완전한 관리 공약이 였 다. 재 리용을 장려 하기 위하여 모둘을 재 리용하는데 50〜100딸 
라의 현금을 보상해 주도록 하였는데 모둘이 실지 로 재 리용될 때 보상을 하였 다. 더우기 
관리 자의 예 산은 그들이 관리하는 프로젝 트가 높은 수준에 서 재 리용되 게 될 때 늘어 난 
다. 지 어 달마다 보수를 받는 재사용자도 있다. 

이 결과 다음과 같은 일 이 있 었다. 1988년에 재 리용수준은 14%였다. 이 것은 회 사에 
서 타산한데 의하면 백 만딸라를 들인것 으로 된 다. 그다음에 는 재 리용수준이 20%로 올라 
갔고 1993년 에 는 50%로 예 견 한다고 타산되 였 다. GTE 가 재 리 용계 획 을 그렇 게 강하게 밀 
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고 나간 리유는 그때까지 총체적으로 천만딸라이상 절약할것을 예견한것이다. 

GTE 재 리용계 획 은 많은 흥미 있는 측면들을 보여 주었 다. 첫째 로，새 로운 모둘이 추 
가되 였 다고 하더 라도 재 리용에 쓸수 있는 모둘의 총수는 1988년에 190개 로부터 1990년에 
는 128개로 작아 졌다. 그것은 바로 GTE 자료봉사기구와 같은 기업체들에서는 재리용가 
능한 구성부분들을 가지고 거대한 명세목록을 작성할 필요가 없다는것을 보여 주었다. 
둘째 로，보다 많은 보상를 위하여 큰 모둘 (1 만개 이 상의 코드) 에 대 하여 관심 을 둔것 이 다. 
보다 작은 모둘들을 재 리용하려 고 한 NASA 의 경험과 대 비적으로 GTE 는 큰 모둘들을 
재리용하는데서 성공하였다. 이러한 차이는 임의의 재리용프로그람에 대하여 관리공약을 
취 하는것 이 얼마나 중요한가를 강조하고 있다. 


8. 3. 5. 를레트-패카드회사 


흘레트-패카드회 사는 회 사의 다른 여 러 국들에 서 재 리용프로그람을 실 현하였 다 [ Lim ， 
1994]. 일 반적 으로 이 런 프로그람들은 재 리 용된 결 과 쏘프트웨 어 의 품질 이 개 선되 였 다는 
견지 에서 성 공적이 였 다. 여 기서 는 두개의 특성 을 가진 프로그람을 론의 하고 세번째 는 
8.5.4 에서 고찰하기로 한다. 

쏘프트웨어 기 술국의 제 조업 에 종사하는 생 산과에 서 는 1983년부터 우연적 인 재 리용프 
로그람을 가지 고 있 었다. 이 과에 서 는 제 조업 에 서 의 지 원계 획작성 에 필 요한 쏘프트웨 어 
를 개 발하였 다. 재 리용하기 위하여 선택 된 구성 부분들은 Pascal 과 SPL ( HP 3000 콤퓨터체 계 
상에 서 동작하는 체 계쏘프트웨어 를 위한 언 어 )언 어 로 작성되 였 다. 새 로운 코드에 대 한 
오유률은 1,000행되 는 코드당 ( KLOC ) 4.1 개 의 오유발생 으로 된 다. 그러 나 재 리용코드에 
대 하여서 는 KLOC 당 0.9 개 의 오유발생 으로 된다. 재 리용의 결과 전체 적 인 오유률은 
KLOC 당 2.1 개의 오유로 떨어 졌으며 51% 감소된것으로 된다. 생산성은 1992년에는 57% 
로 늘어 났으며 월공수는 1.1 KLOC 까지 늘어 났다. 놀랍게도 그다음해에는 프로젝트가 
승산이 없게 되였다. 

1987년부터 흘레트-패카드회 사의 싼디에 고 기 술도형 ( STG ) 국에 서 는 재 리 용프로그람을 
계 획 하였 다. 이 국에 서 는 작도기 와 인쇄 기 를 위 한 점 웨 어 를 개 발하고 유지 정 비 

한다. C 언어 로 2만행되 는 작은 제 품이 3년동안 개 발되 고 그다음 재 리용되 였 다. 1987년과 
1994년 (1994 년자료는 평 가자료임 )사이 에 재 리용프로그람에 드는 전체 비 용은 160만딸라 
였고 560만딸라가 절약되 였다. 오유률도 KLOC 당 1.3 개의 오유로 되 여 24% 감소되였다. 
또한 생산성은 월공수가 0.7 KLOC 로 40%까지 올라 갔다. 마지막으로 제품배포시간도 
24%까지 줄어 들었다. 

STG 재리용프로그람개발에 드는 비용에도 흥미를 끌고 있다. 재리용가능한 점웨어구 
성 부분을 개 발하는데 드는 비 용은 류사한 재 리용불가능한 구성 부분을 개 발하는데 드는 
비 용보다 다만 11% 더 들었 다. 통합단계 에 드는 비 용은 재 리용불가능한 구성 부분을 개 
발하는데 드는 비 용의 19%였다. 즉 구성 부분이 매 번 재 리용될 때 마다 드는 비 용은 그 
구성부분을 령상태에서 개발하는데 드는 비용의 약 1/5뿐이였다. 

훌레 트-패카드회 사는 현재 다음과 같은 더 좋은 구상을 가지 고 있 다. 하나의 인쇄 기 
모형 으로부터 얻 은 점 웨어를 그것 에 련이 은 모형 에서 리용할 대 신에 쏘프트웨 어제품개 발 
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지침을 구상하였다 [ Toft , Coleman and Ohta , 2000]. 이것에 대해서는 8.5.4 에서 서술하였다. 

이러한 5개의 실례연구에 대한 총체적인 교훈은 바로 재리용이 실천에서 가능하다는 
것 이며 비 용을 절 약할수 있다는것 이 다. 그러 나 관리 자측이 재 리용을 밀고 나가는것 이 기 
본이다. 

마지막 실례연구는 성공적 이 라고 하기보다는 경계해 야 할 이 야기 이 다. 

8. 3. 6. 유럽우주항공국 

1996년 7월 4일에 유럽우주항공국은 아란 5호로케트를 처음으로 발사시켰다. 쏘프트 
웨어결함으로 로케트는 리륙한 다음 37 s 만에 떨어 졌다. 로케트와 탄두의 비용은 5억딸 
라였고 이 것은 현재까지 비 용이 가장 많이 든 쏘프트웨 어 고장이 였다[■指 z 6 guel and Meyer , 
199刀. 

실패의 기본원인은 64 bit 옹근수를 16 bit 부호 없는 옹근수로 변환하려고 시도한데 있었 
다. 변환될 수는 2 16 보다 더 컸다. 그리하여 Ada 에 서 exception (실 행 시 오유)이 발생하였 다. 
유감스럽게도 코드에는 이러한 오유를 처리하는 명확한 오유조종프로그람이 없었기때문 
에 쏘프트웨어 가 폭주되 였다. 이것은 한 기판콤퓨터 를 마비시 켰고 그다음 아란 5호로케 트 
를 파피 시켰 다. 

사실 오유를 일으킨 변환은 불필요한것이였다. 리륙하기전에 관성체계를 바로 잡도 
록 정확하게 계산이 진행되였다. 이러한 계산은 리륙하기전 9 s 동안 정지되였다. 그러나 
초읽기가 계속 진행되면 초읽기가 다시 시작된 다음에 관성체계를 재개시하는것은 몇시 
간동안 진행될수 있다. 그러한 현상을 막기 위하여 비행을 시작한 다음에 50 s 동안 계속 
계산을 진행하여 비행을 잘하게 한다(그럼 에도 불구하고 일 단 리륙하면 관성체계를 조절 
하는 방도는 없게 된다.). 이런 조종과정이 쓸데없이 계속되여 실패를 일으켰다. 

유럽우주항공국은 효률적 인 쏘프트웨 어품질 보증구성 부분을 병 합한 쏘프트웨 어개 발공 
정 을 리 용하였 다. 그러 면 왜 Ada 코드에 자리 넘 침 과 갈은 가능성 을 조종하기 위 한 례 외 조 
종프로그람이 없었는가? 콤퓨터 에 지 나친 부담을 주지 않기 위하여 자리넘 침을 초래하지 
않는다고 본 변환들을 대책이 없이 내버려 둔것이였다. 문제로 되는 코드는 10년전의것 
이였다. 그것은 아란 4호로케트를 조종하는 쏘프트웨어률 더 시험도 하지 않고 변경도 
시키지 않은 채로 재리용하고 있었다. 수학적으로 분석한데 의하면 질문에서 제기된 계 
산은 아란 4호에 서 는 완전히 안전하였 다는것 이 증명되 였 다. 그러 나 그 분석 은 아란 4호 
에 대 하여서는 정확하지만 아란 5호에 대 하여서는 정 확치 않다고 하는 확실한 가정 에 기 
초하여 진행되였다. 따라서 분석은 더는 정확하지 못하였으며 코드는 자리넘침에 대한 
가능성 을 고려할수 있는 례 외 조종프로그람의 보호를 요구하였 다. 성 능상 제 한은 없 었지 만 
아란 5호의 Ada 코드전반에 걸쳐 례외조종프로그람은 명백히 있었다. 만약 관련 있는 모 
둘에 변화되 여 야 할 수는 2 16 보다 작아야 한다는 주장을 포함하고 있었더 라면 시험시 에 
나 그리고 제품이 설치된 다음에라도 assert 명령을 리용하여 아란 5호를 파피시키지 않았 
을수도 있었다 [ J 6 z 6 guel and Meyer , 199刀. 

재리용의 경험과 관련하여 주요한 교훈은 바로 하나의 문맥안에서 개발된 쏘프트웨 
어는 다른 문맥에서 재리용될 때 반드시 재시험되여야 한다는것이다. 즉 재리용된 쏘프 
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트웨어모둘은 그자체로서는 재시험할 필요는 없지만 재리용된 제품으로 통합된 다음에는 
재시 험되 여 야 한다. 또 하나의 교훈은 6.5.2 에서 론의한바와 같이 수학적 인 증명의 결과 
에 대 하여 전적 으로 믿 는것 은 현명하지 못하다는것 이 다. 

다음에 재 리용에 대 한 객체지향파라다임의 영 향에 대 하여 검 토한다. 

8.4. 객체와 재리용 

합성 -구조화설 계 ( C / SD ) 리 론이 약 30여 년전에 처 음으로 제 기 되 였 을 때 리 상적 인 모둘 
은 기 능적 인 응집도를 가지 는 모둘이 라는 주장이 있 었 다 (7.2.6). 즉 모둘이 다만 한가지 
작용을 수행하면 그것 은 전형 적 인 재 리용후보로 간주 되 였 으며 이 와 갈은 모둘의 유지 정 
비는 쉬워 질것으로 예상되였다. 이러한 론법에서 결함은 기능적인 응집도를 가진 모둘 
은 자체포함되지도 않고 독립적이지도 않다는것이다. 대신 자료에 대하여서는 처리해야 
한다. 만일 그러한 모둘이 재 리 용되 면 처 리하여 야 할 자료도 재 리용되 여 야 한다. 새 제 품 
에 있는 자료가 원래의 제품에 있는 자료와 갈지 않으면 자료가 변화되여야 하든가 또는 
기 능적 인 응집도를 가진 모둘이 변화되 여 야 한다. 그러 므로 흔히 믿 군 하는것 들과 반대 
되 게 기 능적 인 응집 도는 재 리 용에 서 는 리 상적 인것 이 못된 다. 

고전적 인 C / SD 에 따르면 그다음 가장 좋은 류형 의 모둘은 정 보적인 응집도를 가진 
모둘이다 (7.2.7). 최근 그러한 모둘은 본질적으로 하나의 객체 즉 어떤 클라스의 실례라고 
인정되 고 있다. 잘 설계된 객체 는 특정한 실세계의 실체 에 대 하여 모든 측면을 모형화하 
지 만 자료와 그 자료를 처 리하는 작용의 실현을 숨겨 버 리 기 때 문에 그것은 쏘프트웨어 의 
기 본구성블로크로 된다. 이 리하여 객 체지향파라다임 이 정 확히 리용되 면 결과로 되는 모 
둘(객체)은 정보적인 응집도를 가지며 이것은 재 리용을 촉진시 킨다. 

8. 5. 설계 및 실현단계에서의 재리용 

설계단계에서 아주 다른 형태의 재리용이 가능하다. 재리용되는 자료는 한개 또는 
두개의 모둘로부터 완성된 쏘프트웨어제품의 구성에 이르기까지 다양할수 있다. 이제 여 
러가지 형태의 설계재리용과 일부 실현단계에서 진행되게 되는 재리용에 대하여 검토를 
진행 한다. 


8.5.1. 설계의 재리용 

제품을 설계할 때 설계림 성원은 초기의 설계단계에서부터 모둘이나 또는 콜라스가 
현재의 프로젝트에서 리용될수 있도록 한다. 이런 형태의 재리용은 은행업무나 항공운수 
체계와 갈은 특정한 응용령역에서 쏘프트웨어를 개발하는 기업체들에 대하여서는 특히 
공통적이다. 기업체는 앞으로 재리용하기 위하여 설계요소들을 보관해 놓고 설계자들로 
하여 금 그것 들을 재 리 용하도록 고무해 줌으로써 이 런 형태의 재 리 용을 촉진시 킬수 있 다. 
이 형태의 재리용은 한계가 있지만 두가지 우점이 있다. 첫째로, 시험된 모둘설계는 제품 
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에 병합된다. 따라서 전반적인 설계는 처음부터 진행할 때보다 더 빨리 그리고 질이 더 
좋게 작성될수 있다. 둘째로, 모둘의 설계를 재리용할수 있으면 그 모둘의 실현도 재리 
용할수 있다. 


1) L) 

그림 8-2. 네가지 류형의 설계재리용 

검은 부분은 각각 T ) 서고나 도구틀， L ) 틀거리， C ) 설계패런， S ) 틀거리，도구틀， 

세 설계패런을 포함한 쏘프트웨어구성에 있는 설계재리용을 의미한다. 

이러한 방법은 그림 8-2 의 가)에서 보여 준바와 같이 서고재리용으로 확장할수 있다. 
서고는 관련 있는 재 리용가능한 부분프로그람들의 모임 이 다. 실례 로 쏘프트웨 어개 발자들은 
행 렬전위 나 고유값람색 과 갈은 일 반적 인 과제 들을 수행할수 있는 부분프로그람을 작성한 
다. 대 신 LAPACK 2.0 (Anderson et al „ 1995) 과 같은 과학서 고를 구입 하게 된 다. 그다음 
필요할 때 마다 과학서고에 있는 부분프로그람들은 앞으로의 쏘프트웨어 에서 리용되 게 된 
다. 객체지향파라다임 에 대 한 인기 가 올라감에 따라 과학쏘프트웨어를 위한 LAPACK ++ 
[ Dongarra , Pozo , and Walker , 1993], DiffPack [ Langtangen , 1994], C - XSC[Klatte et al „ 1991] 
등의 클라스서고들이 개발되였다. 

또 하나의 실 례 로서는 도형사용자대 면부 ( GUI ) 를 위한 서 고가 있다. GUI 방법 들을 처 
음부터 작성할 대 신에 GUI 클라스서 고나 도구틀 즉 GUI 의 모든 측면을 조종할수 있는 클 
라스들의 모임 을 리용하는것 이 훨씬 더 편리하다. 이 와 관련한 많은 GUI 도구틀들이 있 다 
[Flanagan and Loukides , 1997]. 

서 고를 재 리용하는데서 문제 는 흔히 서 고들이 재 리용가능한 설계 가 아니 라 재 리 용가 
능한 부분프로그람의 모임으로 되 여 있다는것 이 다. 도구틀 역시 일반적으로 설계재 리용 
이 아니라 코드재리용을 촉진시킨다. 객체지향파라다임을 리용할 때 이 문제는 열람기 
즉 계 층나무로 현시하는 CASE 도구를 리용함으로써 완화될 수 있 다. 설 계 자는 그다음 계 
층나무로 된 서고를 자세히 살펴 보면서 여 러가지 클라스의 항목을 조사하여 어느 콜라 
스를 현재의 설계 에 적 용할수 있는가를 결정한다. 

서 고와 도구틀의 재 리용과 관련한 중요한 측면은 그림 8-2 의 자 )에 서 보여 준바와 
같이 설계자가 제품의 전반적인 조종론리에 대하여 책임을 진다는것이다. 서고나 도구틀 
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은 쏘프트웨어개발공정들에 배포되여 제품의 특정한 조작을 병합하는 설계의 부분들을 
제공해 준다. 

다른 한편 응용프로그람의 기본틀거 리는 조종론리를 제공해 주는 서고나 도구틀을 
반전한것이다. 즉 개발자들은 특정한 조작의 설계에 책임이 있다. 이에 대해서는 다음 부 
분에서 서술한다. 

8. 5. 2. 응용프로그람의 틀거리 

그림 8-2 의 니에 서 보여 준바와 같이 응용프로그람틀거 리 ( a 夕夕 //cafew framework ) 는 
설계 의 조종론리 를 병 합한다. 틀거 리 를 재 리용할 때 개 발자들은 개 발되 는 제 품의 응용상 
특정한 조작들에 대 하여 설계 를 진행해 야 한다. 응용상 특정 한 조작들이 삽입 되 는 곳을 
흔히 지적점(/배 따 o /) 이라고 한다. 

용어 틀거 리 ( framenwi ) 는 최 근에 보통 객 체 지 향응용프로그람틀거 리 라고 부론다. 실 
례 로 [ Gamma , Helm , Johnson , and Vlisside , 1995] 에서 는 틀거 리를《 쏘프트웨 어 의 특정 한 
클라스에 대 하여 재 리용가능한 설계 를 진행할수 있는 협 조적 인 클라스들의 모임》으로 
정의하였다. 그러나 8.3.1 에 있는 레이손미싸일체계관리국 실례연구를 고찰해 보자. 그림 
8-1 은 그림 8-2 의 니와 동등하다. 달리 말하면 1970년대의 레이손 COBOL 프로그람론리 
구조는 오늘날의 객체지향응용프로그람틀거 리 에 대 한 고전적 인 조상이다. 

응용프로그람틀거 리의 한가지 실례 는 콤파일 러의 설계 를 위한 클라스의 모임 이 다. 
설계 림은 언어와 그리고 목적하는 기계 에 특정한 클라스들을 제공해 주어 야 한다. 그다 
음 이러한 클라스들은 그림 8-2 의 L ) 에서 흰칸으로 보여 준바와 같이 틀거리에 삽입된 
다. 틀거리에 대한 또 하나의 실례는 ATM 을 조종하는 쏘프트웨어를 위한 클라스들의 모 
임 이다. 여 기서 설계 자들은 은행 업 무망의 ATM 에 의하여 제 공되 는 특정한 은행 업무봉사 
를 위한 클라스들을 제공해 주어야 한다. 

틀거 리 를 재 리용하면 두가지 리유로 하여 도구틀을 재 리용할 때보다 제 품개 발을 더 
빨리 진행할수 있도록 한다. 첫째로, 설계가 틀거리를 리용하여 재리용되면 될수록 처음 
부터 설계를 진행하게 되는 경우에는 그만큼 더 적어 지게 된다. 둘째로, 틀거리(조종론 
리 )를 리용하여 재 리용되 는 설 계부분이 조작보다도 설 계 하기 가 더 힘 들기때 문에 도구틀 
을 재 리용할 때보다 결과적 인 설계 의 품질도 더 좋아 지 게 된다. 서 고나 도구틀을 리용 
하여 재 리용할 때 틀거 리 의 실 현도 역 시 재 리용될 수 있 다. 개 발자들은 틀거 리 들에 대 한 
이 름과 호출약속을 리용해 야 하지 만 그 비 용은 적 다. 또한 조종론리 가 응용프로그람틀거 
리를 재 리용하는 기 타 다른 제 품들에서 시 험되 고 유지정 비 자들이 이 미 그것과 같은 틀거 
리 를 재 리 용하는 또 다른 하나의 제 품을 유지 정 비 할수 있 기 때 문에 결 과적 인 제 품은 쉽 게 
유지정비되게 된다. 

응용프로그람틀거 리를 내놓고도 많은 코드틀거 리들이 있다. 처음으로 성공한 코드틀 
거 리 중에 는 마킨토쉬 상에 서 동작하는 응용쏘프트웨어 를 개 발하는 틀거 리 인 MacApp 가 있 
다 [ Wilson , Rosenstein , and Shafer , 1990]. 마이 크로쏘프트기 초클라스서 고 ( MFC ) 는 Windows 
응용프로그람에서 GUI 를 구축하도록 하는 틀거 리들의 큰 집합이 다. MFC 응용프로그람은 
창문의 이동과 크기조절 그리고 대화창을 리용한 입력처리, 마우스를 찰칵하는것과 갈은 
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사건처리라든가 차림표선택과 같은 사건처리 등과 같은 표준창문조작들을 진행할수 있다 
[ Holzner , 1993]. Object Windows Library ( OWL ) 을 갱 신 한 Borlands Visual Component 
Library ( VCL ) 도 기능상 MFC 와 류사하다. 그러나 VCL 은 완전히 객체지향적이다. 이것이 
바로 VCL 이 MFC 보다 우월 하다고 보는 많은 리유들중의 하나이 다 [ Wells , 1996]. 

이제는 설계패런에 대하여 보기로 하자. 

8. 5. 3. 설계패턴 

크리 스터 퍼 알렉싼더(다음의 《 알고 싶은 문제》를 보시 오.)는 다음과 같이 말했 다. 

《매개 패턴은 우리의 주위환경에서 자주 일어 나는 문제들을 표현해 준다. 같은 방법으 
로 두번 진행하지는 않고 백만번이상 리용할수 있는 그러한 방법으로 문제해결의 핵을 
나타낸다 .》 [Alexander et al „ 1977] 그는 비록 건물이나 기 타 다른 구조적인 객체에 대한 
문맥에서 서술하고 있지만 이 견해는 다 설계패런에 마찬가지로 응용할수 있다. 

설계패 턴은 특정한 설계를 창조하도록 주문작성해 야 하는 호상작용하는 클라스들의 
모임 형 태 로 일 반적 인 설계문제를 풀어 나가는 해결책 으로 된다. 이 에 대 하여서는 그림 
8-2 의 미에서 보여 주었다. 선들로 련결된 컴컴한 칸들은 호상작용하는 클라스들을 의 
미한다. 컴컴한 칸에 있는 흰칸들은 이러한 클라스들이 특정한 설계를 위하여 만들어 져 
야 한다는것 을 의 미한다. 


알:2 싶 e ©제 

객체지향쏘프트웨 어공학분야에서 가장 영향력 있는 사람들중의 한 사람은 크러 스토퍼 
알렉싼더인데 그는 객체나 쏘프트웨어공학에 대하여 거의나 아무것도 모르는 세계 억으로 
유명 한 건축설 계 가이 다. 그는 책 [Alexander et al., 197 기에 서 도시 나 건물, 방들과 ; 원 등 
을 서 술하는 건축을 위한 패 런언어 들을 서 술하였 다. 그의 착상을 쏘프트웨 어 공학; •들 특 
히 소위 4 인그룹 [Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides] 을 卜아 들 
여 적용하였다. 설계패 런에 관해서 가장 잘 팔리는 책 [Gamma, Helm, Johnson, and lisside 
s, 1995] 은 객체지향집 단이 널리 받아 들인 알렉싼더의 구상을 반영하였다. 

패런은 기타 다른 분야들에서도 제기된다. 실례로 비행장에 착륙할 때 비행조 증사는 
정 확한 착륙패 런 4- 방향이 나 고도 등을 알아야 한다. 또한 옷재 단에서 패 런은 특 1 한 옷 
들을 만드는데 반복적으로 리용될수 있는 형래들이다. 패런의 개념은 그자체로서; ■ 의미 
가 없다. 중요한것은 쏘프트웨어개발과 특히 설계에 패런을 응용하는것이다. 


패턴들이 어떻게 쏘프트웨어개발을 방조하는가를 리해하기 위하여 다음의 실례를 고 
찰해 보자. 이제 어느 한 쏘프트웨어기업체가 부분품생성프로그람 즉 도형사용자대면부 
를 구축하는데 방조를 줄수 있는 도구를 개발하려고 한다고 하자. 여러가지 도구(창문이 
나 단추, 차림 표，화면흐름띠 와 갈은)들을 령상태 에서 개 발해 야 할 대 신 개 발자들은 응용 
프로그람안에 서 리 용되 는 부분품들을 정 의 하고 있는 부분품생 성 프로그람에 의 하여 만들 
어 진 클라스들의 모임을 리용할수 있다. 




문제는 응용프로그람이 Linux , Mac OS , Windows 를 비롯한 많은 서 로 다른 조작체 계 
상에 서 동작할수 있도록 하는것 이 다. 부분품생 성프로그람은 이 세 가지 조작체 계 를 지 원 
하는것 이 다. 그러 나 부분품생성프로그람이 응용프로그람에 대 하여 하나의 특정한 체 계상 
에 서 동작하는 부분프로그람을 힘 들게 코드작성하면 앞으로 그 응용프로그람을 수정 하기 
가 힘들게 되고 생성된 부분프로그람을 다른 조작체계상에서 동작할수 있는 다른 부분프 
로그람으로 교체한다는것도 힘들게 될것이다. 실례로 응용프로그람이 Linux 에서 동작할 
예정이라고 하자. 그러면 차림표가 생성될 때마다 매번 통보문 create Linux menu 가 보내 
진다. 그러나 이제는 응용프로그람이 Mac OS 상에서 동작하여야 한다. create Linux menu 의 
매 실체들이 create Mac OS menu 로 교체되 여 야 한다. 큰 응용프로그람에 대 하여 Linux 에서 
Mac OS 로 변화시 키 는것 은 힘 들고 오유를 범 하기 쉽 다. 

해 결책 은 바로 응용프로그람을 특정한 조작체 계와 떼 여 놓는 방법 으로 부분품생성 
프로그람을 설계 하는것 이 다. 이것 은 설계패 런추상제 작소여 fc / rac 厂를 리 용하여 할 
수 있다 [ Gamma , Helm , Johnson , and Ylissides , 1995]. 그림 8-3 에 결과적 인 설계를 보여 
주었 다. 이 그림 에 서 추상클라스와 그 추상(가상)방법 의 이 름은 빗선체 로 되 여 있 다(추 
상콜라스는 비 록 기 초클라스로 리용될 수 있 다고 하여 도 실 체 화될 수 없는 클라스이 다. 
그것은 보통 적어도 하나의 방법을 포함하고 있다.). 그림 8-3 의 곡대기부분에 추상클라 
스 Abstract IV/rfg 산， actorj 가 있다 (7.7 에서 언급한바와 같이 UML 규정에서는 클라스는 
매 단어의 첫문자가 대문자인 굵은체로 되여 있어야 한다.). 이러한 추상콜라스는 많은 
추상방법 들을 포함하고 있다. 간단히 하기 위해서 여 기서 는 다만 두가지 즉 create menu 
와 create window 를 보여 준다. 그림 에서 아래 로 가면서 Linux Widget Factory, Mac OS 
Widget Factory, Windows Widget Factory 는 Abstract Widget Factor 어의 구체 적 인 부분 
클라스들이다. 매 콜라스는 주어 진 조작체 계상에서 동작할수 있는 부분품을 창조하는 
특정한 방법 을 포함한다. 실례 로 Linux Widget Factory 에 있는 create menu 는 차림 표객 
체 가 Linux 상에서 동작할수 있도록 창조되게 한다. 

또한 매개의 부분품에 대하여 추상클라스들이 있다. 여기서는 A & sfra 산 와 

Abstract Window 두가지를 보여 준다. 매개가 다 세개의 조작체계에 대하여 각각 하나의 
구체적 인 부분클라스를 가지고 있다. 실례로 Linux Menu 는 Abstract 에 대한 하나 
의 구체적 인 부분클라스이 다. 구체적 인 부분클라스 Linux Widget Factory 안에 있는 방법 
create menu 는 Linux Menu 형의 객체가 창조되게 한다. 

창문을 창조하기 위 하여 응용프로그람안에 서 Client 객 체 는 Atorac# Widget Fac 切 /y 의 
방법 create w/m/ow 에 통보문을 보내 야 하며 다형 성 은 정 확한 부분품이 창조된 다는것 을 
담보해 준다. 이제 응용프로그람이 Linux 에서 동작한다고 하자. 우선 Linux Widget 
Factory 형(클라스)의 객 체 Widget Factory 가 창조된다. 그다음 파라메 터 로서 Widget Factory 
를 넘겨 주는 Abstract Widget Fac 切巧의 방법 create w / rn/ow 를 추상화한 통보문은 구체적 
인 부분클라스 Linux Widget Factory 안에 있는 방법 create window 에 대 한 통보문으로 
해 석된다. 차례 로 방법 create window 는 Linux Window 를 창조하기 위 해서 통보문을 보낸 
다. 즉 이것은 그림 8-3 에서 제 일 왼쪽에 있는 수직 으로 그은 점선으로 표시하여 주고 
있 다. 
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이 그림 에서 위험한 측면은 응용프로그람안에 있는 Client 와 부분품생성프로 = 
1 Abstract Widget Factory，Abstract Menu, Abstract Window 세 개의 대면부 
추상클라스들이 라는것 이 다. 추상클라스들의 방법 들이 abstract ( C ++ 에 서 는 virti 



























기때문에 이러한 대면부들은 그 어떤 조작체계에 대하여 특정한것이 아니다. 이리하여 
그림 8-3 의 설계는 응용프로그람을 조작체계와 분리시켜 놓는다. 그림 8-3 의 설계는 그 
림 8-4 에서 보여 준패런 AZw / rac ， Facto ” 의 실체이다. 이 패런을 리 용하기 위 하여 특정 
한 클라스들은 일 반적 인 이 름들을 Concrete Factory 2와 Product B 3 과 같이 교체 한다. 
그때문에 그림 8-2 의 미에서는 설계패런에 대한 기호적인 표현이 컴컴한 칸에 흰칸을 
포함하고 있으며 흰칸은 설계에서 이러한 패턴들을 재리용하기 위하여 제공되여야 할 세 
부들을 보여 주고 있다. 패턴들은 다른 패런들과 호상작용한다. 이것을 그림 8-2 의 근 ) 에 
서 기호적으로 표현해 주었다. 그림 8-2 의 이에서 중간에 있는 패턴들의 왼쪽아래 블로 
크도 패 런이 다. 문헌 [Gamma, Helm, Johnson, and Vlissides, 1995] 에 있는 문서편집기의 
실례연구는 8개 의 서 로 다른 호상작용하는 패 런들을 포함하고 있다. 그것은 바로 실천에 
서 무엇 이 일 어 나는가 하는것 이 다. 즉 제 품의 설계 가 바로 하나의 패린을 포함하고 있 
다는것은 흔히 있을수 있는 일이 아니다. 

도구틀과 틀거 리 를 가지 고 하기때 문에 설계패 턴들을 재 리용하면 그 패 턴의 실현도 
역 시 재 리용할수 있다. 더우기 분석패 턴도 객체지향분석 을 방조해 줄수 있다 [Coad, 1992; 
Fowler, 1997a], 마지막으로 패 런외 에도 반대 패 턴 (an/ 中 atom) 들이 있 다. 즉 이 사실에 대 하 
여서는 다음의 《알고 싶은 문제》에서 서술하고 있다. 


알:2 싶은 ©제 

반대 패 런은 《 분석 마비》(분석 단계 에 서 아주 많은 시 간과 노력 이 느는)나 
하나의 객체 가 거의 모든 작업 을 한다고 하는 객체지향제품을 설계하는것과 같" 어떤 
프로젝트를 실패시 킬수 있는 행위 이 다. 처 음에 반대패 런에 관한 책 [Brown et al „ ?98]을 
쓰게 된 기본동기는 모든 쏘프트웨어제품들가운데서 거의 1/3이 취소되고 2/3는 사용이 
200%로 초과되게 되고 80%이상은 실패라고 생각하였기때문이다. 


8. 5. 4. 쏘프트웨어구성방식 

쏘프트웨 어 제 품의 구조는 객 체 지 향적 이 며 관들과 려 과기 들 (UNIX 구성 부분) 또는 
의 뢰 자-봉사기 로서 서 술할수 있다. 그림 8-2 의 H) 은 도구 틀과 틀거 리 그리 고 세개 
의 설계패턴들로 구성된 구성방식설계를 기호적으로 보여 주고 있다. 

쏘프트웨 어 구성 방식분야는 전체 적 인 제 품의 설계 에 응용되 기 때 문에 그것의 구성부분 
에 의한 제 품의 조직 과 제 품의 준위조종구조，통신과 동기 화문제 , 자료기 지 와 자료호출, 
구성 부분들의 물리 적 인 분포, 성능, 설계방도의 선택 을 포함하여 여 러 가지 설계상 문제 점 
들을 내 포하고 있다 [Shaw and Garlan, 1996]. 이 리 하여 쏘프트웨 어구성 방식은 설계패 턴보 
다도 훨씬 더 넓은 범위의 개념으로 된다. 

사실상 쇼와 갈랜 [Shaw and Garlan, 1996] 은 다음과 같이 말했다.《 추상적 으로 쏘프 
트웨 어구성 방식 은 체계 가 구축되는 요소들의 식 별과 그리 고 그러한 요소들속에서의 호상 

작용, 그러 한 구성부분들을 안내해 주는 패턴들, 그러 한 패턴들에 대한 제한을 포함한다.》 
앞의 단락에 서 라렬 한 많舍 항목들을 제 외 하고도 쏘프트웨 어구성 방식 은 부분적 인 항목으 
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로서 패 런을 포함하게 된다. 이것은 바로 그림 8-2 의 n ) 에서 쏘프트웨 어구성 방식의 구 
성요소들로서 세개의 설계패런들을 보여 주고 있는가 하는 리유로 된다. 

쏘프트웨 어구성 방식 이 재 리용될 때 설계의 재 리용에 대 한 우점들은 더 욱더 커지게 
된다. 구조의 재리용을 실천적으로 실현하기 위한 하나의 방도는 쏘프트웨어제품개발지침 
을 리용하는것 이 다 [ Lai , Weiss , and Pamas , 1999; Jazayeri , Ran , and van der Linden , 2000]. 
그 착상은 바로 많은 쏘프트웨어 제 품에 공통인 쏘프트웨 어 구성 방식 을 개 발하며 새 제 품을 
개 발할 때 이 구조를 실증하는것 이 다. 흘레트-패카드회 사는 아주 다양한 인쇄 기 들을 제 작 
하였 으며 새 로운 모형 을 끊임 없 이 개 발하고 있 다. 훌레 트-패카드회 사는 지 금 매 새 로운 
인쇄 기모형 에 대 하여 실증된 점 웨어구조를 가지 고 있다. 그 결과는 매 혹적 이 였다. 실례 로 
1995년과 1998년사이에 새 로운 인쇄기모형 에 대 한 펌 웨어를 개 발하는데 드는 시 간당 공수 
는 1/4로 줄어 들었고 그 펌 웨어를 개 발하는데 드는 시 간은 1/3로 줄어 들었다. 그러 나 재 
리용은 늘어 났다. 최근의 인쇄 기들에서는 점 웨 어구성부분의 70%이상이 재 리용되 고 있으 
며 원래의 제품들에서 거의 나 변화되지 않았다 [ Toft , Coleman , and Ohta , 2000]. 

8. 6. 재리용과 유지정비 

재리용을 촉진시키게 된 기본리유는 개발공정을 단축할수 있었다는데 있다. 실례로 
많은 주요한 쏘프트웨 어기업체들은 새 제품을 개발하는데 요구되는 시간을 절반으로 줄 
이려고 하고 있으며 재리용은 이러한 요구를 충족시키는데서 기본전략으로 되고 있다. 
그러 나 그림 1-2 에서 보여 준바와 같이 제품을 개 발하는데 1딸라가 소비되고 제품을 유 
지정비 하는데는 2딸라가 소비된다. 그러 므로 재 리용을 하게 되 는 두번째 리유는 제 품을 
유지 정 비하는데 드는 시 간과 비 용을 줄이 려 는데 있 다. 사실상 재 리용은 개 발보다도 유지 
정비에 더 큰 영향을 주고 있다. 

제 품의 40%는 그보다 먼 저 개 발된 제 품으로부터 재 리용된 구성 부분들로 구성되 여 
있으며 이러한 재리용은 전체 제품에 대하여 다같이 적용된다고 가정하자. 즉 명세서 
40%는 재 리용된 구성 요소들로 구성되 여 있으며 설계 의 40%와 코드모둘의 40%, 지 도 
서의 40% 등에 대하여서도 마찬가지로 고찰할수 있다. 그러나 이것은 전체적인 제품 
을 개 발하는데 드는 시 간이 재 리용을 하지 않았을 때보다 40% 더 적 다는것을 의미하 
지 않는다. 첫째 로, 일 부 구성 부분들은 새 제 품에 알맞게 고쳐 져 야 한다. 재 리용된 
구성 부분의 1/4이 변경 된다고 가정 하자. 구성 부분이 변경되 면 그 구성 부분에 대 한 문 
서도 변경된다. 이밖에 변경된 구성부분은 시험되여야 한다. 둘째로, 코드모둘이 변경 
되 지 않고 재 리용되 면 그 모둘의 단위 시 험 은 필 요하지 않다. 그러 나 그 모둘에 대 한 
통합시험은 여전히 필요하게 된다. 그래서 지어 제품의 30%가 변경되지 않고 재리용 
된 구성 부분들로 구성되 여 있 다고 하면 완성 된 제 품을 개 발하는데 필 요되 는 시 간은 
기껏해서 약 27% 더 적어 지게 된다 [ Schach , 1992]. 평균적으로 쏘프트웨어예산의 
33%가 개발하는데 소비된다. 결국 재리용이 개발비용을 27%까지 줄이면 12년〜15년 
까지 수명 을 가진 제 품의 전체 적 인 비 용은 재 리용의 결과로 대 략 9%까지 줄어 들게 
된다. 이 사실에 대해서는 그림 8-5 에서 보여 주었다. 
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활동 

제품수명에 대한 전체 

재 리용으로 인한 제품수명의 

비용의 퍼센트 

비용절약퍼센트 

개발 

33% 

9.3% 

유지 정 비 

67 

17.9 


그림 8-5. 새 제품의 40%가 재리용된 요소로 구성되고 재리용된것의 3/4은 
변화되지 않았다는 가정하에서 보여 준 평균 비용절약퍼센트 

류사하면서 도 보다 장황한 인수들은 쏘프트웨 어개 발공정 의 유지정 비구성 부분에 응용 
할수 있다 [ Schach ，1994]. 앞에 진행한 가정대로 하면 유지정비에서 재리용의 효과는 그림 
8-5 에서 보여 준바와 같이 전반적으로 약 18%의 비용을 절약하는것으로 된다. 명백히 
말해 서 재 리용이 주는 중요한 영 향은 개 발에 있는것 이 아니 라 유지 정 비 에 있 다. 기 본리 
유는 바로 재리용된 구성부분들이 일반적으로 잘 설계되여 있고 철저하게 시험되였으며 
리해 하기 쉽 게 문서 화되 여 있어 세 가지 형 태의 유지 정 비 를 모두 간단히 진행할수 있게 
한다는데 있다. 

주어 진 제 품에 대 하여 실제 적 인 재 리용률이 가정한것 보다 더 낮으면(혹은 더 높으 
면) 재 리용의 리 익성 은 달라 지 게 된다. 그러 나 전반적 인 결과는 같다. 즉 재 리용은 개 발 
보다도 유지정비에 더 큰 영향을 미친다. 

다음은 이식성에 대하여 보기로 한다. 

8. 7. 이 식 성 

쏘프트웨어의 비용이 끊임없이 늘어 나는것은 비용을 조절하는 수단을 찾아 낼것을 
절박하게 요구하고 있다. 그 한가지 방도는 제품이 전체적으로 여러가지 종류의 하드웨 
어-조작체계결합에 대 하여도 쉽게 동작할수 있도록 하는것 이 다. 제품을 개 발하는데 드는 
일부 비용은 다른 콤퓨터들에서도 동작할수 있도록 개 발된 판본을 판매 함으로써 보상될 
수 있다. 하지만 다른 콤퓨터들에서도 쉽게 동작할수 있는 쏘프트웨 어를 개 발하는 가장 
중요한 리유는 4년에 한번씩 의 뢰 자측이 새 로운 하드웨 어 를 구입 하고 모든 쏘프트웨 어 들 
이 그 새로운 하드웨어에서 동작할수 있게 바꾸기때문이다. 새로운 제품을 령상태에서 
개 발하는것 보다 그 제 품을 새 로운 를퓨터 에서도 동작할수 있게 하는것 이 비 용이 훨씬 더 
적을 때 그 제품에 대하여 이식을 할수 있다 [ Mooney , 1990]. 

더 정 확히 말하여 이 식가능성 은 다음과 같이 정 의할수 있다. 어 떤 제 품 P 가 콤파 
일러 신에 의하여 콤파일되여 원천콤퓨터상에서 실행된다고 하자. 이를테면 하드웨어구 
성배치 가 조작체 계 O 에 놓인다. 기능상은 제품 P 와 같지 만 콤파일 러 (그에 의하여 
콤파일 되 고 목적콤퓨터 에 서 동작한다는데 로부터 제 품을 戶'라고 한다. 즉 하드웨 어구성 
배치 及■'는 조작체계 O ' 에 놓인다. 제품 ?를 제품 T 5 ' 로 변환하는데 드는 비용이 제품 P' 
를 처 음부터 새 로 코드작성하는데 드는 비 용보다 현저 히 적 다면 제 품 P 는 이 식 가능 
(portable) *1 -- JL 말한다. 
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전체적으로 볼 때 쏘프트웨어를 변환하는 문제는 각이한 하드웨어구성배치와 조작체 
계 그리고 콤파일러사이에 호환성이 없는것으로 하여 중요하게 제기된다. 이에 대하여 
매 측면을 차례로 검토한다. 

8. 7. 1 . 하드웨어의 비호환성 

현재 하드웨 어구성배 치 산에서 동작하는 제품 ^를 하드웨 어구성배 치 /厂에 설치 하려 
고 한다. 피상적으로 보면 이것은 단순하다. 제품 i 3 를 好의 하드구동기로부터 DAT 레프에 
복사하고 그것 을 산'에 옳긴 다. 하지 만 만일 分'가 예 비복사를 위하여 Zip 구동기 를 리용하 
였다면 이것은 옮길수 없다. 즉 DAT 레프는 Zip 레프구동기에서 읽을수 없다. 

이제 제품 P 의 원천코드를 를퓨터 에 물리적으로 복사하는 문제가 해결되였다고 
하자. 여기서 公'가 요에 의 하여 만들어 진 비트패 런을 해석 할수 있다는 담보는 없다. 일반 
적 으로 여 러 가지 종류의 많은 문자코드가 있는데 여 기서 가장 일반적 인것은 확장2진식 W 
진변환코드 (EBCDIC) 와 정 보변환용표준코드 (ASCII), 7bit ISO 코드이 다 [Mackenzie, 1980]. 만 
일 公가 EBCDIC 를 사용하고 H'7\ ASCII 방식 을 리 용한다고 하면 H’ 는 戶를 쓸수 없는것 으 
로 취급한다. 이와 류사하게 개인용콤퓨터 PC 는 일반적으로 마킨토쉬형식의 자료를 읽을 
수 없으며 반대로 마킨토쉬는 PC 형식으로 된 자료를 읽을수 있다. 

이러한 차이가 있게 되는 력사적인 고찰이 있지만(즉 서로 다른 제작자들에 대하여 
독립 적 으로 일 하는 연구사들은 서 로 다른 방법 으로 갈은 기 능을 수행하는 제 품을 개 발하 
였다.) 그것들을 존속시키는데는 제한된 경제적리유가 있다. 이것을 고찰하기 위하여 다 
음과 같은 가상적 인 환경을 생각해 보자. MCM 콤퓨터제작업체는 수천대의 MCM-1 콤퓨 
터 를 판매하였 다. MCM 은 현재 MCM-1 보다 모든 면에 서 성 능이 더 높고 비 용은 훨씬 더 
적은 새 콤퓨터 MCM-2 를 설계제 작하여 팔려 고 하고 있다. MCM-1 이 ASCII 코드를 리용 
하고 있으며 9bit 짜리 4개로 구성된 36bit 단어를 가지고 있다고 가정하자. 이제 MCM 의 
책 임콤퓨터 설계가는 MCM-2 는 EBCDIC 코드를 사용하며 8bit 짜리 두개로 구성된 16bit 단어 
를 가지 고 있다고 하였 다. 그다음 판매부서에서 는 현제 의 MCM-1 소유자들에게 MCM-2 이 
그와 동일한 경쟁대상의 콤퓨터보다 3만 5천딸라 적게 비용이 들지만 현존쏘프트웨어와 
자료를 MCM-1 형식에서 MCM-2 형식으로 변환하는데 20만딸라의 비용이 들게 될것이라고 
말해 주어 야 한다. MCM-2 를 재 설계하는 과학적 인 론거 가 아무리 훌륭하다고 해 도 판매 
상 고려해 야 할 문제 는 새 로운 콤퓨터 가 낡은 콤퓨터 와 호환가능하다는것 을 담보해 주는 
것 이 다. 그다음 판매원은 현재의 MCM-1 소유자들에게 MCM-2 콤퓨터가 그 어떤 다른 경 
쟁자의 를퓨터보다 비 용이 3만 5천딸라 적 게 들뿐아니 라 잘못 알고 다른 제 작자에 게 서 
산 손님들은 3만 5천딸라로 지 내 비 용을 많이 들였 다는것과 또한 현존쏘프트웨어 와 자료 
를 비 MCM 콤퓨터 형 식 으로 전환시키 는데 비 용이 약 20만딸라를 '들여 야 한다고 말해 줄수 

聲다. 

앞에서 본 가상적 인 환경에서 실지 현실세계로 돌아 와서 보면 현재까지 가장 성공적 
인 계렬의 를퓨터는 IBM system/360-370 계렬 이였다 [Gifford And Spector, 198刀. 이러한 계렬 
의 콤퓨터 들이 성 공하게 된것 은 바로 그러한 콤퓨터 들사이 에 완전한 호환성 이 있는데 있 
다. 즉 1964년에 개발된 IBM System/360 모형 30상에서 동작하는 제품은 2001 년에 개발된 
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IBMS /390 모형 IC 5 상에 서 변화시키 지 않고도 동작할수 있 다. 그러 나 IBM System /360 모형 
30상의 OS /360 체 계 하에 서 동작하는 제 품은 Sun Enterprise 10000상의 Solaris 체 계 와 같이 전 
혀 다른 20이년 기 계 상에 서 동작시 키 기 전에 상당한 수정 을 진행하여 야 한다. 난관의 일부 
는 바로 하드웨 어의 비호환성과 조작체계의 비호환성때문이 다. 

8. 7. 2. 조작체계의 비호환성 

임의의 콤퓨터에 대하여 일감조종언어 ( JCL ) 는 일반적으로 아주 다르다. 이러한 일부 
차이는 문장론적이다. 즉 수행적재가능한 프로그람을 실행시키기 위한 지령은 한 콤퓨터 
에 서 는 @ xeq , 다른 콤퓨터 에 서 는 // xqrt , 세 번째 콤퓨터 에 서 는 . exc 일 수 있 다. 제 품을 다 
른 조작체 계상태 로 바물 때 문장론적차이는 하나의 JCL 로부터 다른 JCL 로 지 령을 번역 
하여 간단히 조절할수 있다. 그러나 기타 다른 차이는 더 심각하다. 실례로 일부 조작체 
계 는 가상기 억 을 지 원 하고 있 다. 이 제 조작체 계 가 제 품에 대 하여 크기상 128 Mb 까지 허 
락하지 만 특정한 제 품에 대 하여 할당된 실제의 주기억 령역은 8 Mb 라고 하자. 그러면 사 
용자의 제품이 256 Kb 크기의 페지들로 분할배치되고 다만 이 페지들가운데서 32개의 페 
지가 일정한 시 간 기 억에 상주하게 된다. 나머지 폐지들은 디스크상에 있으며 가상기 억 
조종체 계 에서 요구한대 로 교환이 이 루어 진다. 결과 제 품은 크기상 효과적 인 제 한을 받 
지 않고 작성 될수 있 다. 그러 나 가상기 억 조종체 계하에 서 성 과적 으로 실현되 는 제 품이 제 
품크기 상 물리 적 인 제 한이 있는 조작체 계 상에 서 동작하게 되 자면 전체 제 품은 크기상 제 
한을 받지 않도록 겹쳐놓이기법을 리용하여 다시 작성하여 련결하여야 한다. 

8. 7. 3. 수자처리쏘프트웨어의 비호환성 

제품이 한 기계로부터 다른 기계로 이식될 때 혹은 지어 서로 다른 콤파일러에 의하 
여 콤파일 될 때 산수연산처 리결 과는 서 로 다를수 있 다. 16 bit 기 계 즉 단어크기 를 16 bit 로 
하고 있는 콤퓨터상에 서 옹근수는 보통 한 단어 (16 bit ) 로 표현되 며 두배 정 확도옹근수는 두 
개의 련결된 단어 (32 bit ) 로 표현된다. 그러나 일부 언어실현에서는 두배정확도옹근수를 포 
함하지 않고 있다. 실례 로 표준적 인 Pascal 은 두배 정확도옹근수를 포함하지 않고 있다. 그 
러므로 옹근수들이 오직 16 bit 로 표현되는 를퓨터로 이식될 때 Pascal 에서 옹근수가 32 bit 
를 리용하여 표현되는 콤파일러와 하드웨어-조작체계구성배 치상에서 정확히 기능을 수행 
하는 제 품들은 실패할수도 있 다. 2 16 보다 더 큰 옹근수를 류동소수점 수(형 태 는 실수)로 
표현하는것은 명백히 할수 없다. 왜냐하면 옹근수는 정확히 표현할수 있지만 류동소수점 
수는 일반적으로 오직 가수부와 지수부를 리용하여 근사적으로 표현할수 있기때문이다. 

Ada 는 옹근수형 의 범 위 와 류동소수점 수형 태 의 정 확도를 설 정 할수 있 기 때 문에 Ada 에 서 
는 이 문제를 해결할수 있다. Ada - 유럽 이식성처 리그롭은 Ada 의 이식성을 담보하기 위한 
앞으로의 권고목록을 작성 하였다 [Nissen and Wallis , 1984]. 

Java 와 관련하여 8개의 기 본자료형 이 설정되 였다. 실례 로 형 int 는 항상 부호 있는 
32bit 두개 의 보수로 실 현 하였 고 형 float 는 항상 32bit 를 차지 하고 류동소수점 수를 위 한 
IEEE 규격 754를 만족시 킨다 [ANSWEEE 754, 1985]. 따라서 Java 에 서 는 수계 산을 목적 으로 
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그 어떤 다른 C 언어 에 기 초한 객체 지향프로그람작성언어들과는 달리 실제상 임의 ] 
어도 타당한 C++ 언어 인것 이 다. 따라서 기 업체 들은 자기들의 현존 C 쏘프트웨어를 5 
지 않고도 C 언어에세,^^언어에로 전환할수 있다는것을 깨달았다. 그들은 구조회 ^ 
임으로부터 객체지향파라다임으로 끊임없이 전진할수 있었다. Java 에 대한 문헌들< 
주 맞다들게 되_는 말은 《 Java 는 C++?f 되였어야 했을것이다.》이다. 그밖에 스트 s 
트루프가 고스링 처 럼 총명 하기 만 하였 더 라면 C ++ 언 어 가 Java 언 어 로 되 였 을것 이 러 는 
다. 반대로 만일 C ++ 언어가 진짜 C 언어를 초월한 언어로 되지 못했더라면 다른 1 
언어 에 기초한 객체지향프로그람작성언어들과 같은 길을 걸었을것 이 다. •%'불필코 < 
을것 이 다.、(法+•언어 가 인기 있는 언어 로서의 지위를 차지한후에 야 C ++ 언어 에 있나 ■ 
에 반응하여 Java 언어가 설계되였다. Java 언어는 C 언어를 초월한 언어가 아니다. 을 
Java 언어에는 지적자변수가 없다. 그러므로 《 Java 언어는 C ++ 헌어 가 포저 히 될수 J 
것 이 다.》라고 말하는것 은 보다 정 확한것 이 다. 

끝으로 Java 언어가 다른 모든 프로그람작성언어들처럼 자체의 약점을 가지고 \ 
것을 알아야 한다. 그밖에도 일부 령역(호출규칙과 같은)에서 C4 +언어는 Java 언어- . 
월하다 [Schach, 1997]. 앞으로 _언어 가 계속 지배적 인 객체지 향프로그람작성 언- 
겠는지 Java 언어나 어떤 다른 언어가 그 자리를 대신 차지하겠는지 하는것은 두고 5 
할것 이 다. _ 

8. 7. 4. 콤과일러의 비호환성 


이식성은 어떤 제품이 그에 대한 콤파일러가 거의나 존재하지 않는 언어로 실현된다 
면 이 루어 질수 없 다. 만일 그 제품이 CLU [ Liskov , Snyder , Atkinson , and Schaffert , 1977] 
와 갈은 전문언어 로 실현된다면 목적콤퓨터 가 그 언어 를 위한 콤파일 러 를 가지 고 있지 
못한 경우에 그것 을 다른 언어 로 다시 작성하여 야 한다. 다른 한편 어떤 제 품이 COBOL , 
FORTRAN , Lisp , Pascal , C , C ++ 나 Java 와 같은 일 반언 어 로 실 현된 다면 목적 하는 를퓨터 
를위한 그런 언어의 콤파일러나 해석프로그람을 찾을수 있다. 

어떤 제품이 표준 FORTRAN 과 같은 일반적인 고급언어로 작성되였다고 하자. 리론상 
으로는 그 제 품을 한 콤퓨터 에 서 다른 콤퓨터 로 이 식하는데 문제 가 없 다. 그러 나 사실 은 
그렇지 않다. Fortran 95[ ISO/IEC 1539-1, 199 刀로 알려 진 ISO/IEC FORTRAN 규격이 있기 
는 하지만 콤파일러 작성자가 거기에 매달릴 근거는 없다 ( Fo _ 95 에 대하여 더 알고 싶으 
면 다음의 《 알고 싶은 문제》를 보시 오.). 실례 로 판매 부서가《새 로운 확장된 FORTRAN 
콤파일러》를 권유할수 있도륵 FORTRAN 에서 흔히 찾아 보지 못하는 추가적인 특징을 




지 원할 결정 을 할수 있다. 반대 로 극소형콤퓨터 의 콤파일 러 가 완전한 FORTRAN 실현을 
할수 없을수도 있다. 또한 콤파일러를 개발하는데 기한이 주어 졌다면 관리자는 후에 수 
정 하여 완전한 표준형 을 지 원할 의 도에 서 미 완성 품을 내 놓기 로 결정할수도 있 다. 원천콤 
퓨터에 있는 를파일러가 Fortran 95 의 초월언어를 지원한다고 가정하자. 또한 목적콤퓨터 
가 표준 Fortran 95 의 실현이 라고 가정하자. 그 원천콤퓨터에서 실현된 제품이 목적콤퓨터 
에 이 식 될 때 초월 언 어 로부터 구성 된 비 표준 Fortran 95 를 리 용하는 제 품의 부분을 다시 
코드작성하여 야 한다. 그러 므로 이 식 성 을 보장하기 위하여 프로그람작성 자들은 표준 
FORTRAN 언 어 의 특징 만을 리용하여 야 한다. 


알고 싶© g 제 

프로그람작성언어 의 이 름은 그것 이 준말일 때 큰 글자로 쓴다. 실례 로 ALGOL ALGO 
rithmic Language), COBOL(COmmon Business Oriented Language) 과 FORTRAN(Fl Rmula 
TRANSlator) 을 들수 있 다. 반대 로 기 타 다른 모든 프로그람작성 언어 들은 큰 글자: . 시 작 
하며 이름에 있는 나머지글자(있다면)들은 작은 글자로 되여 있다. 실례로 Ada, ( 

Java 와 Pascal 을 들수 있다. 그런데 FORTRAN 규격위원회는 1990 년판부터 시작하여 "ortran 
으로 쓰기_로 결 정하였 다. 


초기 COBOL 규격은 미국의 콤퓨터제조업체들과 정부 및 개 인사용자위 원회 인 Conference 
on DAta SYstems Language ( CODASYL ) 가 개 발하였 다. 국제 규격 화기 구 ( ISO ), 국제 전 자기 술 
위원회 ( IEC ) 의 제 22 차소위원회의 계 1 공동기술위원회가 현재 COBOL 규격을 책임지고 있 
다 [ Schricker , 2000]. 그런데 COBOL 규격은 이식성을 조장하지 않았다. COBOL 규격은 공식 
적으로는 수명이 5 년이지만 매개 성공적인 규격이 결코 그 이전의것에 대한 초월언어인 
것은 아니다. 또한 우려되는것은 많은 특징이 개별적인 실현자들에게 맡겨지며 부분언어 
(하위언어)는 표준 COBOL 이 라는 용어 로 불리우며 그 언어 를 확장하여 초월언어 를 구성하 
는데는 제한이 없다 [ Wallis , 1982]. 

현재의 COBOL 의 초보적 인 표준언어 인 OO - COBOL (2002 년에 최종승인을 받을것으로 
계획 됨)은 완전히 객체 지향적이다 [ ISO/IEC 1989, 2000]. 대비적으로 Fortran 95 는 단지 객 
체에 기초한것이몌 Wegner , 1992] 즉 계승과 콜라스는 Fortran 95 에서는 실현되지 않는다. 
Fortran 95 객체들은 따라서 그자체의 권한에 있는 실체이며 클라스의 실체는 아니 다. 그 
다음의 FORTRAN 규격인 Fortran 2000 은 완전히 객체지향적인것으로 볼수 있는데 이 책 
을 쓸 당시 Fortran 2000 규격 의 발표예 정 날자는 2002 년 11 월 이 다. 

몇개의 서 로 다른 Pascal 규격 들이 있다. 처 음으로 젠센 ( Jensen ) 과 워 스 ( Wirth ) 가 그 언 
어에 대한 정의를 하였고 [Jensen and Wirth , 1975] 그다음은 ANSI 규격 (ANSWEEE 770 X 3.97, 
1983) 였다. 이렇게 규격이 지나치게 많음에도 불구하고 Pascal 의 부분언어와 초월언어는 
풍부하다. 실례로 모든 Pascal 규격은 처리절차와 함수이름들이 인수로서 넘겨 질수 있다 
고 명기되 여 있다. 하지만 그 특징 이 결코 Pascal 콤파일 러 가 일반적 으로 지원하는것은 아 
니다. 반대 로 Pascal 의 많은 초월 언어 들이 실현되 였 다. 실례 로 Pascal 의 일부 실현은 모름 
지 기 C 언 어 와 경 쟁 하기 위 하여 비 트별 and 와 or 와 같은 비 표준비 트처 리 조작을 병 합하고 
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있다. 또한 현재 수많은 Pascal 실현은 Pascal 에 대한 객체지향확장을 포함하고 있다. 

미국국가규격협회 ( ANSI ) 는 프로그람작성 에서 C 에 대 한 규격을 승인하였다 [ ANSIX 3.159, 
1989]. 그 규격 도 1990 년에 ISO 가 승인하였 다. 대부분의 C 를파일 러 들은 원래언어의 규격 
을 매우 엄격 하게 고수하고 있다 [Kemighan and Ritchie , 1978]. 이 것은 거의 모든 C 를파일 
러 작성 자들이 이 식 성 이 있는 C 콤파일 러 /7 cc [ Johnson , 1979] 의 표준앞단을 리용하기때 문 
이 다. 결과 대 다수의 콤파일 러 들에 의해서 인정 되 는 언어 들은 동일 하게 된다. 일 반적 으로 
C 언어제품은 하나의 실현에서 다른 실현에 쉽게 이식된다. C 언어의 이식성을 보조하는 
것은 lint 처리기이다. 그것은 제품이 목적를퓨터에 이식될 때 난관을 초래할수 있는 구성 
뿐아니 라 실현의 존적 인 특징 을 결정하는데 사용할수 있다. 유감스럽 게 도 lint 는 문장론과 
정적 인 의 미 론만을 검사하며 따라서 그릇되게 증명하지 않는다. 하지 만 앞으로의 문제 들 
을 해결하는데서 상당한 도움이 될수 있다. 실례로 C 언어에서 옹근수값을 지적자에 할당 
하는것 이 합법적이며 또 지적자를 옹근수값에 할당하는것도 합법적 이 다. 하지만 lint 에 
의해서는 금지된다. 일부 실현에서 옹근수와 지적자의 크기(비트수)는 갈은것이지만 크기 
들 이 다른 실 현 에 서 는 다를수 있 다. 이 전 종류의 잠재 적 인 미 래 의 이 식 성 문제 는 lint 에 의 
하여 정지될수 있으며 거슬리는 부분은 다시 코드작성함으로써 제거될수 있다. 

C ++ 언어의 규격 ( ISO/ffiC 14882, 1998) 은 1997 년 11 월에 여러 국가규격위원회 (ANSI 포 
함)의 한결 갈은 찬동을 밤았다. 그 규격 은 1998 년에 최 종비 준을 받았다. 지 금까지 유일하 
게 성 공적 인 언 어 규격 은 Ada 참고지 도서 [ ANSI / MIL - STD -1815 A , 1983] 에 서 구체 화된 
Ada 83 규격 이다 (Ada 에 대한 배경지식을 알고 싶으면 다음의 《알고 싶은 문제》를 보시 
오.). 1987 년말까지 Ada 라는 이름은 Ada 공동프로그람사무소 ( AJPO ) 의 등록상표였다. 상표 
의 소유자로서 AJPO 는 Ada 라는 이 름이 규격 과 정 확히 일 치하는 언어실현들을 위 해서 만 
법적으로 리용될수 있다고 제정하였다. 그러나 부분언어와 초월언어는 특히 금지되였다. 
Ada 콤파일 러들을 타당하게 하기 위한 기구가 설치되 였으며 타당성검사공정 에 성과적으 
로 통과된 콤파일 러 만이 Ada 를파일 러 라고 불리 울수 있 었 다. 그리하여 등록상표는 규격 과 
그로부터 이 식성 을 시 행하는 의미 로 리 용되 였 다. 

Ada 라는 이름이 더는 등록상표가 아니기때문에 규격의 시행은 다른 기구들을 통하여 
수행되고 있다. 타당성검사를 받지 못한 Ada 를파일러는 시장에 거의 없거 나 전혀 없다. 그 
러므로 강한 경쟁력은 Ada 를파일러개발자들이 타당성검사를 받고 그로부터 Ada 규격과 일치 
하는것으로 확인된 자기들의 콤파일러를 가지도록 하고 있다. 이것은 Ada 83[ ANSI / MIL - 
STD -1815 A , 1983] 과 Ada 95 [ ISO/IEC 865 文 1995] 를 위한 를파일 러 들에 적 용하였 다. 


알고 싶 e @제 

1970년대 초에 미 국방성 ( DoD ) 은 자기의 쏘프트웨 어와 관련한 문제 들을 예 민 하: 인식 
하게 되였다. 보다 걱정스러운 문제의 하나는 적어도 450개의 서로 다른 언어가 D D 제품 
들에 사용되 고 있다는 사실이 였다. 이 런 확산에 포함된 주요한 의 미는 보통 환경 비서도 
어려운 유지정비가 이런 언어의 혼란을 해결할 능력이 있는 유지정비프로그람작성 다들을 
찾 아야 하므로 거의 불가능한것으로 되였다는것 이 다. 이와 함께 쏘프 트웨 어개발 ᄌ 유지 
정비를 지원할 도구가 1차적 으로 나서는데 주로寒 그 매 언어를 위한 충분한 CA E 도구 
틀을 사거 나 구축하는데 막대한 비 용이 들기 때 문이 였 다._ 
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사(내장형를퓨터에 있는 쏘프트웨어, 6.4.4 을 볼것)와 관련하여 g 편은 
개 무력군종들이 자기 마음에 드는 실 시 간언어 를 가지 고 있 S 다. 즉 
지원하고 있고 해군은 CMS -2 를 장려하였으며 공군이 선택 &것은 
■히 말하여 내장형쏘프트웨어와 관련된 형편은 불리하였고 유지 장비에 
다면 더 불리해 질 수밖에 없 었 다. 

I •웨어 는 수십 , 수백 만의 코드행 으로 커 지 게 되 고 10~15년의 누명 을 
기간에 요구가 변화되는데 따라 자주 변화되게 되는 경향이 U 었다 
7 1 내 장형쏘프트웨:는 거의나 항상 땅크, 무인조종기 나 직승: 와 갈' 
장된 를퓨터의 크기가 일반적으로 제한적이라는 점에서 볼 때 공간상 
1-. 더 구나 실 시 간쏘프트웨어 의 시 간제 한이 항상 존재한다. 마지 각으로 
고도로 믿음성이 있는것이여야 한다. 쉽게 말하면 일단 탄도미 바일이 
1였다면 그 어떤 종류의 실패가 발견되는 경우에 시간적으로 대늦으 
1프트웨어 를 수정할수 없게 된 다. 

• 모든 무력군종들에 일 반화할수 았쓸 고급언어 를 찾아 내 기 그 한 세 
하였다. 대 학생，산업전문가, 군사전문가들이 포함되 여 었는 림 I ■로부 
소았는데 그중 4 건은 더 발전시키기로 하였다. 심사자들이 경쟁 7 1 업체 
하기 위하여 제 안된 언 어 들에 Blue, Green, Red, Yellow 라는 코 드이 름 
비 적 으로 우승자는 프랑스의 호네 이웰 불 (Honeywell Bull) 의 젠 사 츠바 
>1 끄는 주로 유럽 림 인 Green 이 되 였 다. 그래 서 Ada 참고지 도乂 : ANSI/ 
53] 에 풀색표지 를 하게 되 였다. 최 근까지 계산기계협회 의 Ada= 관한 
SIGAda) 에 의 하여 출판된 주요 Ada 잡지 인 Ada Letters 들 i 풀색 또지 를 
는 초기의 이름 DoD-1 처 럼 Green 이 라는 이름이 마음에 들지 않 5 다. 해 
Cooper) 가 시 인 로드 바이론 (Lord Byron) 의 딸인 라브레 이스 (L< /elace) 
이름을 따서 이름을 Ada 라고 할것을 제 기하였다. 그 녀 자는 li 기전 
Babbag 의 분석엔진을 위한 프로그람을 작성하였 다. Babbag 의 g 계 는 
I 기 술의 제 한성 으로 하여 분석엔 진은 제 작할수 없 었 다. 국방성 하관은 
f 인 리론 (Lytton) 백작의 부인으로부터 Ada 라는 이름을 사용할 근 을 허 
•ruffel, Fisher, and Whitaker, 1980]. 바로 그래서 언어의 이름을 JDA 가 
되였다. 그것은 략어가 아니다. 그것은 세계의 첫 프로그람직 영자인 
-인 인 Ada 의 이 름을 딴것 이다. 

승인을 받아 군사규격 MIL - STD -1815 으로 결정되였다. 수자 815는 
!도이다. 1994년에 Ada 의 수정판이 국제규격화기구와 국제전 斗기술 
았다. 그 규격 [ ISO/IEC 8652, 1995] 이 1995년에 출판되였으므: . 언어 
.다. 여 러 가지 새 로운 특징들 특하는 객체지향성 이 원판 (Ada 8： I 에 첨 


1•학원 국가연구리 사회의 충고에 따라 DoD 는 Ada 가 자기의 모- • 쏘프 




타당성검사증명서는 특정한 조작체계와 특정한 하드웨어에서 실행되는 특정한 콤파 
일 러를 위한것 이 다. 만일 Ada 콤파일 러를 개 발한 기 업체 가 를파일러를 다른 하드웨 어 나 
조작체계구성배 치 에 넘길것을 바란다면 다시 타당성검사를 해 야 한다. 모든 Ada 를파일 러 
를 위한 참고지도서는 부록 6 을 포함하고 있는데 거기에는 Ada 실현에 관한 실현의존적 
인 특성 이 서술되 여 있다. 실례 로 형변환을 취소하고 인수를 단순히 비트패 턴으로 취급 
할수 있다. 그런데 실현은 그러한 항목의 크기에 대하여 제한을 가할수 있다. 

그러면 기술적으로 Ada 제품들을 부록 6 에서 언급된 특성들과 관련한것을 제외하고 
는 완전히 이식가능하게 만들수 있다. 

Java 가 완전히 이식가능한 언어로 되자면 언어를 규격화하고 그 규격을 엄격히 준수 
하도록 하는것 이 필수적 이 다. Ada 공동프로그람사무소와 같이 Sun Microsystems 은 규격화 
실현을 위하여 법적체계를 리용하고 있다. Sun 은 저작권을 얻을수 있는 새로운 언어를 
위한 이 름을 선택하였 다. Sun 은 자기 들의 저 작권을 실시하는 이 른바 위 반자들에 대 하여 
법적행동을 취할것으로 보고 있다. 결국 이식성은 Java 의 가장 위력한 특성들중의 하나이 
다. 만일 Java 의 많은 판본들이 허용된다면 Java 의 이 식성은 진통을 겪게 될것 이 다. 즉 
Java 는 유독 모든 Java 프로그람들이 모든 Java 콤파일러에 의 하여 똑같이 처리될 때에만 
실 지 이 식 가능하게 될 수 있 다. 사회 여 론에 영 향을 주기 위하여 1997 년 에 Sun 은《 순수한 
Java ) 라고 선전깜빠니 아를 벌 렸다. 

Java 의 판본 1.0 은 1997 년 초에 나왔다. 론평들과 비평들에 대응하여 여 러가지 개정된 
판본들이 뒤 따라 나왔다. Java 의 이 러 한 단계 적 인 세 련과정 은 계 속될것 이 다. 언어 가 점 차 
적 으로 수정 되 자면 ANSI 나 ISO 와 같은 규격 화기 구가 초안규격 을 공개발표하고 세 계 각 
지로부터 론평을 받아야 한다. 이러한 론평들은 공식적인 Java 규격을 결속하는데 리용될 
것 이 다. 


8. 8. 왜 이식성이 필요한가 

쏘프트웨 어를 이식 하는데서 나서는 많은 난관들과 관련하여 독자들은 결국 쏘프트 
웨어를 이식할 가치가 있는가 하는데 대하여 의심할수 있다. 8.7 에서 언급된 이식성이 
유익 하다는 론거 는 쏘프트웨어의 비 용이 아마도 여 러 가지 하드웨 어-조작체 계구성배 치 에 
대 하여 제 품을 이 식 함으로써 부분적 으로 공제될 수 있 었 다는것 이 다. 그러 나 쏘프트웨 어 
의 다양한 변종들을 판매하는것 은 불가능하다. 응용프로그람은 고도로 전문화될 수 있고 
그 어 떤 다른 의 뢰 자도 쏘프트웨어 를 필요로 하지 않을수도 있다. 실례 로 어 느 한 주요 
승용차임대 회사를 위하여 개 발된 관리정 보체 계 는 다른 승용차임대 회사들의 운영 에 적 용 
할수 없을수도 있다. 선택 적 으로 쏘프트웨 어 그자체 는 의 뢰 자에 게 경 쟁할수 있는 유리 
성 을 계공해 줄수 있으며 제 품을 복사하여 판매하는것은 경제적 으로 자살행 위 와 다름이 
없게 될것이다. 이 모든 사실들에 비추어 볼 때 이식을 제품이 설계되였을 때 공학적인 
방법으로 제품화하는것이 시간과 비용의 랑비이겠는가? 

이 물음에 대한 대답은 강조해서 말하여 아니다라는것이다. 이식이 필수적인것으로 
되 는 주요한 리유는 쏘프트웨어 제품의 수명 이 일 반적 으로 그것 이 처 음 개 발된 하드웨 어 
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의 수명 보다 더 길 다는것 이 다. 좋은 쏘프트웨어 제품은 15년 혹은 그이상의 수명 을 가질 
수 있다. 반면에 하드웨어는 번번히 최소한 4〜5년마다 변화된다. 따라서 좋은 쏘프트웨 
어 는 자기 의 수명 에 비 하여 3개 혹은 그이 상의 각이한 하드웨 어 구성 배 치 들에 서 실현될 수 
染다. 

이 문제 를 해 결 하기 위한 한가지 방도는 다음과 갈다. 방도는 상승식 으로 호환가 
능한 하드웨어를 구입하는것이다. 거기서 유일한 비용은 하드웨어의 원가뿐이다. 쏘프 
트웨어는 변화시 킬 필요가 없을것 이 다. 그럼 에 도 불구하고 일부 경 우에 제 품을 각이한 
하드웨어에 완전히 이식하는것은 경제적으로 보다 안정할수 있다. 실례로 제품이 첫번 
째 판본을 7년전에 대형콤퓨터상에서 실현될수 있었다고 하자. 비록 그 제품이 그 어 
떤 변화도 없이 실행될수 있는 새 로운 대형콤퓨터를 구입하는것 이 가능할수 있어도 매 
개 사용자들이 탁상우에 하나씩 놓는 개 인용콤퓨터망우에 서 제 품의 다양한 복사본들을 
실현시키는것은 아주 덜 비싼것 같다. 이 실례에서 만일 쏘프트웨어가 이식을 도모하 
는 방식 으로 개 발되 였 다면 제 품을 개 인 용콤퓨터 망우에 서 이 식 하는것 은 재 정 적 으로도 
좋다 • 

하지 만 다른 종류의 쏘프트웨어 들이 있다. 실례 로 개 인용를퓨터 를 위한 쏘프트웨 어 
를 개 발하는 많은 기 업체들은 COTS 쏘프트웨어의 다양한 복사본들을 판매 함으로써 돈을 
번다. 실례 로 표처 리프로그람패 키지 에 대 한 리윤은 작으며 개 발비 용은 가능한껏 보상할 
수 없 다. 리윤을 얻 기 위하여 1만개 (혹은 지 어 10만개 )의 복사본들을 팔아야 한다. 이 점 
에 서 추가적 인 판매 는 순리윤으로 된 다. 그래 서 제 품이 그밖의 추가적 인 류형 의 하드웨 
어들에 쉽게 이식할수 있다면 훨씬 더 많은 돈을 벌수 있다. 

물론 다른 모든 쏘프트웨어 들과 마찬가지 로 제 품은 바로 코드는 아니 다. 또한 지 도 
서를 비롯한 문서작성문제가 있다. 표처리프로그람패키지를 다른 하드웨어에 이식하는것 
은 문서 작성 도 역 시 변화시 킨다는것 을 의 미한다. 그리하여 이 식성은 령상태 에서부터 새 
문서 를 작성하여 야 할 대 신에 목적 으로 하는 구성 배 치 를 반영 하기 위하여 문서 를 쉽 게 
변화시 킬수 있다는것 을 의 미한다. 만일 완전히 새 로운 제 품을 개 발하는것 보다 눈에 익 고 
현존하는 제품을 새로운 콤퓨터에 이식한다면 아주 적은 숙련이 요구되게 된다. 이러한 
리 유로 하여 역 시 이 식 성 이 장려 되 여 야 한다. 

다음에 이 식 성 을 실 현 하는 기 술을 설 명한다. 

8. 9. 이식성실현기술 

이식을 실현하기 위한 한가지 방도는 프로그람작성자들이 또 다른 콤퓨터에 이식할 
때 문제들을 야기시킬수 있는 구성들을 리용하는것을 금지시키는것이다. 실례로 원칙은 
고급언 어 의 표준판으로 모든 쏘프트웨 어 를 개 발하는것 이 다. 그러 나 이 식 가능한 조작체 계 
는 어떻게 개발되는가? 결국 조작체계를 최소한의 일부 아쎔블리어코드가 없이 개발할 
수 있다고 하는것은 생각조차도 할수 없다. 류사하게 콤파일러는 특정 한 콤퓨터 에 대 하 
여 목적코드를 생성하여야 한다. 여기서도 역시 실현의존관계의 구성요소들을 피하는것 
은 불가능하다. 
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8. 9. 1 . 이식가능한 체계쏘프트웨어 

거의 모든 쏘프트웨어개발을 방해할수 있는 실현의존관계측면들을 금지시키는 대신 
보다 더 좋은 기법은 임의의 필요한 실현의존관계의 부분품들을 고립시키는것이다. 이 
기 법 의 실 례 는 UNIX 조작체 계 가 구성 되 는 방식 이 다 [Johnson and Ritchie , 1978]. C 언 어 로 
조작체 계 의 약 9,000행 을 작성하였 다. 나머지 1,000행 은 핵 심부를 구성 하고 있다. 핵 심부 
는 아쎔블리어 로 작성 되 고 매 개의 실현을 위하여 다시 작성되 여 야 한다. C 언어코드의 약 
1,000행은 장치구동프로그람을 구성하고 있다. 즉 이 코드도 역시 매번 다시 작성되여 야 
한다. 그러나 C 언어로 된 나머지 8,000행은 실현될 때마다 크게 변화되지 않았다. 

체 계쏘프트웨어의 이 식성을 크게 하는 또 다른 유용한 기술은 추상화의 준위 를 리용 
하는것 이 다 (7.4.1). 실례 로 도형 표시 부분프로그람을 생 각해 보자. 사용자는 drawline 같은 
지 령을 원천코드에 삽입한다. 원천코드는 콤파일된 다음 도형현시부분프로그람과 련결된 
다. 실행시에 drawline 은 사용자가 서술한대로 화면에 선을 그리도록 한다. 이것은 두개의 
추상화준위를 리용하여 실현할수 있다. 고급언어로 작성된 웃준위는 사용자의 지령을 해 
석하고 지령을 실행시키기 위하여 적합한 낮은 준위모둘을 호출한다. 만일 도형현시부분 
프로그람들이 새로운 형식의 콤퓨터들에 이식된다면 사용자의 코드 혹은 도형현시부분프 
로그람의 웃준위 에 그 어 떤 변화도 없 다. 그러 나 부분프로그람의 아래준위모둘들은 실제 
적 인 하드웨 어와 대화하기때문에 다시 작성되 여 야 한다. 그리고 새로운 를퓨터의 하드웨 
어는 패키지가 이전에 실현된 를퓨터의 하드웨어와 다르다. 이 기술은 또한 ISO - OSI 모형 
의 7개 추상화준위 들에 부합되 는 자료통신쏘프트웨어 를 이 식하는데서 성 과적 으로 리용되 
였 다 [ Tanenbaum , 1996]. 

8. 9. 2. 이식가능한 응용쏘프트웨어 

조작체 계 와 콤파일 러 와 같은 체 계 쏘프트웨 어 보다 응용쏘프트웨 어 와 관련하여 일 반적 
으로 제품을 고급언어로 작성할수 있다. 14.1 에서는 종종 실현언어와 관련하여 그 어떤 
다른 선택 이 없지만 어떤 언어를 선택할수 있을 때 비용 대 리득분석에 기초하여 선택을 
진행하여야 한다고 서술되여 있다 (5.2). 비용 대 리득분석에서 고려하여야 할 한가지 인 
자는 이식성에 주는 영향이 다. 

제품개 발의 매 단계에서 보다 더 이식가능한 제품을 만들 결심들이 채택될수 있다. 
실례 로 일부 를파일 러들은 대 문자와 소문자를 구별한다. 그러한 콤파일 러 들로서 This - Is - 
A - Name 과 this - is - a - name 는 다 각이 한 두개 의 변수로 된 다. 그러 나 다른 콤파일 러 들은 두 
개의 이름을 꼭 갈은것으로 취급한다. 대문자와 소문자들사이의 차이에 의존하는 제품은 
제품을 이식할 때 발견하기 힘든 결함들을 초래할수 있다. 

흔히 프로그람작성언어 에 그 어 떤 선택 이 없는것 처 럼 역시 조작체 계 에 그 어 떤 선택 
이 없을수 있다. 그러나 만일 가능하다면 제품이 실행되는 조작체계는 대중적인것이여야 
한다. 이것은 UNIX 조작체계 에 대 하여 유익한 론의 로 된다. UNIX 는 광범한 하드웨 어상에 
서 실 현되 여 왔다. 더우기 UNIX 혹은 보다 더 정 확하게 는 UNIX 와 같은 조작체 계 들은 
IBM /370 과 VAXVMS 와 같은 대형콤퓨터조작체계상에서 실현되 여 왔다. 개 인용콤퓨터들 
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로 말하면 그것은 Linux 가 가장 널리 쓰이는 조작체계 인 Windows 를 압도할것 인가를 보 
아야 한다. 널 리 실현된 프로그람작성언어 를 리용하는것 이 이 식 성 을 도모하는것 처 럼 역 
시 널리 실현된 조작체 계도 마찬가지다. 

UNIX 형체계에서 또 다른 체계에로 쏘프트웨어를 이식시키는것을 쉽게 하기 위하여 
콤퓨터환경 을 위한 이 식 가능한 조작체 계대 면부 ( POSIX ) 가 개 발되 였 다 [NIST 151， 1988]. 
POSIX 는 응용프로그람과 UNIX 조작체 계사이 의 대 화를 규격 화한다. POSIX 는 응용쏘프트 
웨어를 거의나 문제가 없이 혹은 전혀 그 어떤 문제가 없이 이식시킬수 있는 콤퓨터들로 
확장되면서 수많은 비 UNIX 조작체계상에서 실현되고 있다. 

언어규격들은 이식성 을 실현하는데서 자기의 역 할을 다할수 있다. 만일 개 발기 업체 
들의 코드작성규격들이 오직 규격구성에만 리용될수 있다고 규정한다면 결과로 되는 제 
품은 보다 더 이 식할수 있다. 이 를 위하여 프로그람작성 자들에 게 콤파일 러의 지 원을 받 
거 나 그것 의 리 용이 이 전에 관리 자측의 허 가가 없 이 는 금지 되 여 온 비 표준특성 들의 목록 
을 주어 야 한다. 다른 현저한 코드작성규격들처 럼 이것은 기계 에 의해서 검사될수 있다. 

도형사용자대 면부는 류사하게 표준 GUI 언 어 의 도입 으로 이 식 가능하게 된 다. 이 런 실 
례 들로서는 Motif 와 XI I 이 있 다. GUI 언 어 들의 규격 화는 10.4 에 서 설 명한것 처 럼 GUI 의 중 
요성 이 커 지 는데 맞게 인 간-콤퓨터대 면부들의 이 식가능성 를 필 요로 하는 결 과를 가져 온 
다. 

계 획 작성 은 또한 잠재 적 인 앞으로의 수자적 인 비 호환성 들을 위하여 진행 되 여 야 한다. 
실례로 만일 제품이 앞으로 32 bit 하드웨어상에서만 개발되고 있다면 그것은 보다 더 구식 
인 16 bit 기계 에 이식되 여 야 할것 이며 그렇게 되면 옹근수들은 L _32, 767범위내 에 있어 야 
하고 실수들의 모둘수는 ±10 68 범위내 에 있어 야 한다. 더 우기 정 확도는 6 개의 m 진수자이 
상으로 가정되지 말아야 한다 [ Wallis , 1982]. 8.7.3 에서 설명된것처 럼 이 문제들도 Ada 혹은 
Java 에서 제기될수 없다. 

또한 필요한것은 제품이 구성되는 조작체계와 제품이 이식될수도 있는 앞으로의 조 
작체 계들사이의 호환성 이 잠재적 으로 결여되도록 계 획을 세우는것 이 다. 만일 가능하다면 
조작체 계호출들은 한개 혹은 두개의 모둘에 국부화되 여 야 한다. 임의의 사건에서 모든 
조작체 계호출은 조심 히 문서 화되 여 야 한다. 조작체 계 호출을 위한 문서 작성 규격은 코드를 
읽게 되는 그다음의 프로그람작성자가 현재의 조작체 계 에 대 하여 아무것도 모를것 이 라고 
가정해야 한다. 이것은 종종 합리적인 추측으로 된다. 

앞으로의 이식을 위하여 설치지도서형 태 로 된 문서를 제공하여 야 한다. 그 지도서는 
제품을 이식할 때 제품의 어느 부분을 변화시켜야 하며 어느 부분을 변화시켜야 하는가 
를 강조해야 할것이다. 두 실례들에서 무엇을 해야 하고 또 그것을 어떻게 할것인가 하 
는데 대 하여 자세한 설명 을 주어 야 한다. 마지 막으로 사용자지 도서 나 혹은 조작지 도서 와 
같은 다른 지도서들에서 진행되는 변화들의 목록도 역시 설치지도서에 포함시켜야 한다. 

8. 9. 3. 이식가능한 자료 

하드웨 어 의 비 호환성문제 들은 8.7.1 에 서 지 적하였 다. 그러 나 그러한 문제 들이 해 결된 
다음에는 쏘프트웨어의 비호환성문제들이 남아 있게 된다. 실제로 색인순차파일의 형식 
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은 조작체계에 의해서 결정된다. 즉 각이한 조작체계는 일반적으로 각이한 파일형식을 
가지고 있다. 많은 파일들은 그 파일안에 있는 자료의 형식과 갈은 정보들이 들어 있는 
머리부를 요구한다. 머리부의 형식은 거의나 항상 그 파일이 창조되는 특정한 를파일러 
와 조작체계에 대하여 유일하다. 자료기지관리체계들을 리용할 때는 상황이 더 나빠질수 
있 다. 

자료를 이식하는 가장 안전한 방법은 비구조화된(순차적 인)파일을 만드는것이다. 그 
렇게 되면 이러한 난점은 최소로 되여 목적하는 기계에 이식될수 있다. 이러한 비구조화 
된 파일로부터 목적하는 구조화된 파일이 재구성될수 있다. 두개의 특수한 변화부분프로 
그람을 작성해야 하는데 하나는 원래의 구조화된 파일을 순차적인 형식으로 변환시키기 
위하여 원천기계상에서 실행시키고 다른 하나는 이식된 순차파일로부터 구조화된 파일을 
재구성하기 위하여 목적하는 기계상에서 실행시킨다. 비록 이러한 해결책이 간단한것 같 
지만 복잡한 자료기지모형들사이의 변환이 진행되여야 할 때 이러한 두 부분프로그람들 
은 결코 사소한것이 아니다. 


8. 1 0. 호상조작성 

이제 요구하는데 따라 인쇄 하게 될 문서를 작성 하려고 한다고 하자. 문서에는 매개 
범주에 있는 실제적인 년간 날자별 지출과 함께 수많은 범주들로 된 년간 예산지출이 포 
함된다. 문서에는 또한 재정책임자로부터 정기적으로 갱신되는 통보문을 포함시켜야 한 
다. 이것 을 실현시키 는 한가지 방법 으로서 예산작성 을 위하여 Lotus 1-2-3 과 같은 표처 리 
프로그람을 리 용하고 전체 적 으로 문서 를 작성 하기 위 하여 Microsoft Word 와 같은 문서 처 
리프로그람을 리용할수도 있 다. 그다음 매 번 문서 가 요구될 때 마다 사용자는 미 리 최 근의 
예 산수자들을 반영 하기 위하여 표처 리 프로그람을 갱 신하고 그다음에 는 현재 의 표계 산결과 
를 문서 에 복사한다. 마지 막에 사용자는 재정 책 임 자의 통보문을 갱 신하고 문서 를 인쇄한다. 

한가지 개선된것은 일종의 수입-수출기구를 리용하는것인데 그것은 표처리결과가 변화 
되는데 따라 자동적으로 문서처 리프로그람이 문서에 반영되도록 하는것이다. 그러나 이것도 
역시 리상적 이지 못하다. 매번 사용자가 먼저 표처 리프로그람을 리용하여 표계산결과를 갱 
신하여 야 할 때 마다 문서처 리 프로그람을 리 용하여 문서 를 연다. 필요한것 은 문서 처 리 프로그 
탐과 표처리프로그람이 명백히 두개의 서로 다른 쏘프트웨어판매업체들의 호환불가능한 제 
품이 라는데 도 불구하고 그러한 두 프로그람을 통합하는 방법 이 다. 그러 면 문서 를 이 전처 럼 
문서처리프로그람에서 연 다음 사용자는 마우스를 가지고 표처리프로그람도구를 짧게 찰칵 
하여 문서처 리프로그람안에서 표처 리프로그람을 불러 내게 된다. 

이것은 호상조작성의 실례로서 각이한 판매업체들로부터 서로 다른 프로그람작성언 
어 로 작성 되 고 각이한 종류의 콤퓨터환경 에서 실행 되 고 있는 목적 코드의 호상협 동과정 으 
로 정 의할수 있다. 실례 로 자동화된 금융기 관에 서 자동출납기 ( ATM ) 들의 전국적 인 망을 
생각해 보라. 봉사기는 하나의 기업체에 의해서 개발된 자료기지쏘프트웨어를 실행시키 
는 주콤퓨터 이 다. 의 뢰 자들인 ATM 는 각이 한 기 업 체 들에 서 개 발한 C ++ 코드를 실 행 시 키 
고 있 다. 더우기 통신쏘프트웨어 가 있는데 여 기서 기 본은 안전보장이 다. 이 모든 구성 요 
소들은 ATM 망이 성 공적 으로 기 능을 수행하도록 하기 위하여 함께 동작하여 야 한다. 


260 



COM 과 CORBA 를 비 롯하여 호상조작성 을 촉진시 키 기 위하여 수많은 표준들이 제 기 
되였다. 


8. 10. 1 . COM 

객체 련결 및 매 몰프로그람 ( OLE ) 의 첫 관본은 Windows 3.0 의 한 부분으로서 1990 년 
에 나왔다. 그것 은 앞절에서 설명한 문서처 리프로그람의 문서안에서 표처 리프로그람과 
같은 혼합문서 를 지 원 하기 위하여 마이 크로쏘프트회 사가 설 계하였 다. 그러 나 OLE 역 시 
호상조작성 을 실현하기 위한 문제 에서 부분적 인 해 결에 지 나지 않는다는것 이 인차 리해 
되 였 다. 마이 크로쏘프트회 사는 그다음 호상조작성 이 총체 적 인 목적 을 달성 하기 위하여 
보다 높은 단계 인 구성 요소객 체 모형 ( COM ) 을 개 발하였 다. COM 은 1993 년 5 월 에 OLE 2.0 
의 한 부분으로서 처 음으로 나왔다. 용어 OLE 는 그때 COM 에 기 초한 기 술을 리용하여 
만들어 진 구조물들을 나타내 는데 리용되 였 다. 완전한 이 름인 객 체 련결 및 메몰프로그람 
令 더는 이러한 새로운 문맥에서 뜻이 통하지 않았다. 그래서 OLE 이라는 이름은 세개의 
글자로 준 말로부터 본래 의 이 름으로 변경되 였 다. 1996 년 에 마이 크로쏘프트회 사는 인 터 
네트관련기술과 관련하여 ActiveX 라는 용어를 사용하기 시작하였다. 그러 나 ActiveX 라는 
용어는 인차 COM 관련기술의 두번째 의미로서 OLE 와 갈은 뜻을 가지는것으로 되였다. 
COM 의 분산형 판본이 분산된 를퓨터환경하에 서 호상조작성 을 지 원하기 위하여 1996 년에 
출현 하였다. 

호상조작성을 지원 하는 기본기술은 COM 기 술이 다. 쏘프트웨 어구성요소 Q 가 구성요 
소 표에 봉사를 제 공한다고 하자. 즉 P 는 Q 의 의 뢰 자이다. 모와 Q 는 여 러 가지 각이한 방 
식으로 동작할수 있다. 만일 P 와 Q 가 같읖 공정의 부분들이 라고 하면 모는 Q 를 호출할수 
있다. 다른 한편 만일 P 와 Q 가 같은 기 계 장치상에서 실행되는 각이한 공정들에 있다면 
P 와 Q 는 호상과정 통신의 일 부 형 식 으로 자료통신할수 있 다. 그러 나 만일 각이한 공정 들 
이 망안에 있는 각이한 기 계 들상에서 실현되 고 있 다면 원격 공정호출 ( RPC ) 을 리 용할수 있 
다. COM 의 리면에 있는 착상은 한개의 구성요소가 또 다른 구성요소에 봉사를 제공하게 
되 는 모든 정 황을 위하여 공통기 구를 리용하는것 이 다. 쏘프트웨어 의 모든 부분들은 COM 
의 구성요소(마이크로쏘프트회사는 이것을 객체라고 하였다.)로 실현된다. 매개 구성요소 
는 한개 혹은 그이상의 대면부들을 가지고 있는데 그 매개의 대면부는 한개 혹은 그이상 
의 기 능을 지 원한다(이 것 들을 조작이 라고 하였 다.). COM 구성 요소를 리용하기 위하여 의 
뢰자는 구성요소의 클라스(매 개 COM 구성요소는 특정한 클라스의 실체 이 다.)와 구성 요소 
의 특정한 대 면부를 서 술한 COM 서 고를 호출한다. 그러 면 COM 서 고는 그 클라스의 구성 
요소들을 실체 화하고 선택된 대면부에 지적자를 되돌려 보낸다. 이제 의뢰 자가 그 대면 
부의 기능을 불러 내게 된다. 

마이 크로쏘프트회 사가 명 기한것 처 럼 COM 기 술은 COM 이 아직 객체지 향적 이 지 못하 
다는 점에서 일부 혼돈하기 쉽다. COM 객체는 클라스의 실체 이 다. 하지만 COM 은 계승을 
지원하지 못한다 (7.8). 따라서 COM 은 객체에 기초한것이지만 객체지향적인것은 아니다. 
구성 요소객 체모형확장 COM + 는 Windows 2000 과 함께 출현 하였 다. 이 전 판본과 마찬가지 
로 COM + 도 역시 객체에 기초한것이다. 그러나 COM 의 앞으로의 판본들은 객체지향적인 
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것으로 될수 있다. 


8. 1 0. 2. C 0 RBA 

1989년에 현재 객체지향기술과 관련한 약 800여명의 판매 자들로 이 루어 진 련합체 인 
객체관리그룹 ( OMG ) 이 객체지향체계들의 공통적 인 구조를 개 발할 목적 으로 설 립되 였다. 
특히 공통적 인 객 체 요구중개 구조 ( CORBA ) 는 분산된 환경 내 에서 각이 한 기 계 장치 들에서 
실행 되 는 쏘프트웨 어응용프로그람의 호상조작성 을 지 원한다 [ OMG ，1999]. 즉 CORBA 는 판 
매자들과 망들, 언어들 그리고 조작체계들사이의 호상조작성을 지원한다. OMG 표준들은 국 
제 규격 화기구의 인증을 받았으며 여 기서 CORBA 는 객체지향체 계 를 위한 국제 규격 으로 되 
였 다. 

CORBA 에 서 중심 은 객 체 요구중개 인 ( ORB ) 이 며 이 것 은 분산형 체 계 에 서 객 체 가 
어디에 있는가에 관계없이 의뢰자가 객체의 방법을 호출하도록 한다. 용어 미들웨어 
( middleware ) 는 호상조작성 을 지 원하는 쏘프트웨 어 를 설명 해 주고 있 다. 그리 고 ORB 는 
《 모든 의 뢰 자/봉사기 미 들웨 어 의 모체》라고 불렀 다 [ Orfali , Harkey , and Edwards , 1996]. 
Inprise Visibroker 와 Iona ORBIX 는 현재 리용할수 있 는 많은 CORBA 실 현 가운데 서 두개 의 
CORBA 로 된다. 


8. 10. 3. COM 과 CORBA 의 비교 


표면상 COM 과 CORBA 는 둘 다 호상조작성 에 대 하여 동등하게 지 원하고 있다. 그러 나 
그 둘사이에는 많은 차이가 있다. 여기서 세가지를 고찰하기로 한다. 

첫번째 차이 는 COM 이 세계 최 대의 를퓨터회 사인 마이 크로쏘프트회 사의 제품이며 한 
편 CORBA 는 말그대 로 수백개의 각이한 콤퓨터기업체들에서 온 쏘프트웨어전문가들에 
의해서 개 발된 국제 적 인 표준이 라는것 이 다. 결과 CORBA ORB 제 품들은 현재 COM 보다 
더 광범한 각이한 종류의 를퓨터환경 에 서 실 현되 고 있 다. 더 우기 CORBA 는 기 본 통신기 
구들과는 별 도의것 으로 규정 되 고 있 으며 반면 에 COM 의 통신기 구는 독점 적 인 마이 크로 
쏘프트회 사의 제 품으로 된다. 결과적 으로 각이한 통신기 구를 리용하는 유산적 인 쏘프트 
웨 어 를 가지 고 COM 을 리 용하는것 은 어 렵 다. 

두번째 차이 는 COTS 쏘프트웨어 의 통합과 관련된 다 (2.1). 마이 크로쏘프트회 사는 적 어 
도 그러한 쏘프트웨어 의 80% 를 제 공해 주고 있다. Microsoft COTS 가 마이 크로쏘프트회 
사의 독점 적 인 COM 으로 통합되 기 가 쉽 다고 하는것 은 현재 COTS 쏘프트웨어 를 CORBA 
에 기초한 제품으로 통합하는데 필요한 보다 복잡한 방법들에 비해서 명백한 우월성으로 
된 다. 

세번째 차이 는 CORBA 는 단순하다는 우월 성 을 가지 고 있 다. COM 은 가장 복잡한 마 
이 크로쏘프트기술중의 하나이 다. 즉 COM 을 위한 문서 는 거 의 2,000 페 지 되 며 개 발자는 
역 시 Win 32 (Windows API ) 에 대 해서 자세 히 리 해 할것 을 요구한다. 더 우기 개 발자들은 
COM 이 배 우기 가 어 렵 다는것 을 알려 주었 다. 다른 한편 CORBA 는 200 페 지 이 하로 서 술되 
여 있 고 대 부분의 CORBA 제품을 위한 문서 는 200 〜 300 페 지 정 도이 다. 
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CORBA 와 COM 은 각각 고유한 지 지 자들과 반대 파들을 가지 고 있다. 호상조작성 이 
앞으로 어떻게 실현되여 갈것인가를 보기로 한다. 

8.11. 호상조작성에 대한 앞으로의 동향 

현재 두개의 주요한 호상조작성제품은 COM (8.10.1) 과 CORBA (8.10.2) 이다. 원래는 많 
은 경쟁 자들이 OpenDoc 에 의 한 경쟁 에서 현저 하게 뒤떨어 졌다. 그러 나 많은 다른 제품 
들이 현재 리용되 거 나 개 발되 고 있다. 실례 로 JavaBeans 는 완전히 이 식 가능하고 치 밀 하며 
구조적으로 중성적이고 콤퓨터환경에 대하여 독립적인 응용프로그람작성대면부 ( API ) 로 
되고 있다. Bean 는 작은 규모의 구성요소이 다. Enterprise bean 은 독립적 인 응용프로그람으 
로 리용할수 있거 나 혹은 쏘프트웨어 제 품으로 통합될 수 있 는 보다 큰 규모의 구성 요소이 
다. Enterprise bean 들은 의 뢰 자-봉사기 구조에 서 봉사기 측의 응용프로그람들을 위 하여 우 
선적 으로 리용된 다 [ Valesky , 1999]. 

World Wide Web 는 주요한 호상조작성의미를 가지고 있다. 한가지 선택은 의뢰자-봉 
사기응용프로그람과 Web 에 기초한 응용프로그람들을 통합할수 있는 단일한 구조이다. 
수많은 판매업체들이 이 수요에 직면하고 있다. 실례로 마이크로쏘프트회사는 분산된 인 
터 네 트구조 ( DNA ) 를 개 발하였 다. 

CORBA 가 많은 면에서 COM 에 비하여 우월하다고 하는것이 제기되였다. 그럼에도 불 
구하고 마이크로쏘프트회사는 기업체들에 COM (혹은 집필당시에는 그의 후임인 COM +) 이 
호상조작성을 실현하기 위한 적 합한 표준이 라는것을 납득시 킬수 있는 세계 최대의 콤퓨터 
회사로 되고 있다. CORBA 나 COM 이 지배적인 호상조작성기구로 될것인가 혹은 앞으로 어 
떤 제 품이 우세를 차지하게 될것 인가는 명백하지 않다. 또 다른 가능성 은 두개의 경 쟁적 인 
표준들사이의 호상조작성을 허용하게 될 CORBA 와 COM 의 련결이 있을수 있다는것이다. 

CORBA 와 COM 의 지지자들사이에 경쟁이 있음에도 불구하고 두 진영은 똑같이 확장 
서 술언 어 ( XML ) 에 대 하여 보다 적 극적 으로 나서고 있 다 [ W 3 C , 2000]. XML 은 초본문서 술언 
어 ( HTMC ) 의 확장이 다. HTML 과 같이 XML 은 일 반적 인 통신규약을 개 발함으로써 World 
Wide Web 상에 서 의 호상조작성 을 촉진시 키 기 위 하여 1994년 10월 에 창설된 World Wide 
Web 련 합체 ( W 3 C ) 의 제 품이 다. W 3 C 는 세 계 각지 에 400개 이 상의 성 원기 업 체 들을 가지 고 있 
는 국제 적 인 기 업 체 이 다. 

기 본문제점 은 XML 이 메 타자료언어 즉 자료들을 서 술하는데 리용할수 있는 언어 들 
이 다. XML 의 주요목적 은 Web 상에 서 각이한 자료원천들의 호상조작성 을 개 선하는것 이 다. 
XML 은 HTML 이 오늘날 그러한것 처 럼 Web 상에 서 자료의 전송과 조종에 서 앞으로 중요 
한 역 할을 놀것 으로 보인다. 


O 야 

-I-L 一 I 

8.1 에 서 재 리용을 설명하였 다. 8.2 에서 는 재 리용에 서 나서 는 장애 들에 대 하여 설명한 
다. 재 리용에 주는 객체지향파라다임의 영 향에 대 해서 는 8.4 에서 분석된다. 설계 및 실현 
단계 에서 진행하게 되는 재 리용은 8.5 에서 취급하고 있다. 여 기서 기 본화제는 틀거 리，패 
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런 그리 고 쏘프트웨 어구성 방식이 다. 유지 정 비 에 주는 재 리용의 영 향에 대 해서 는 8.6 에서 
론의 한다. 

8.7 에서는 이식성 에 대 하여 고찰한다. 이식성은 하드웨 어 (8.7.1), 조작체계 (8.7.2), 수자 
처 리쏘프트웨 어 (8.7.3), 를파일 러 (8.7.4) 에 대 하여 일 어 나는 비 호환성 의 방해 를 받을수 있 
다. 그럼 에 도 불구하고 모든 제 품들은 가능한껏 이 식 가능하게 만들기 위 하여 노력 하는것 
이 중요하다 (8.8). 이 식을 쉽게 진행하는 방법 들로서는 일 반적 인 고급언어 들을 리용하는 
것과 제품의 이식불가능한 부분들을 고립시키는 방법 (8.9.1) 그리고 언어표준들에 준하는 
것 (8.9.2) 들이 포함된 다. 호상조작성 에 대 하여 서 는 8 J 0 절 에 서 소개하였 다. 8.10.1 에 서 는 
COM 에 대 하여， 00.2 에 서 는 CORBA 에 대 하여 론의 를 진행 한다. 8.10.3 에 서 는 그것 들을 
서로 비교한다. 8.11 에서는 호상조작성에 대한 앞으로의 추세에 대하여 고찰한다. 

보 충 

이 장에 서 재 리 용의 실 례 연구에 대 한 보충적 인 정 보는 문헌 [Lanergan and Grasso , 
1984; Matsumoto , 1984, 1987; Selby , 1989; Prieto - Diaz , 1991; Lim , 1994; Jezezquel and 
Meyer , 1997; and Toft , Coleman , and Ohta , 200 이 에 서 찾아 볼수 있다. 훌레 트-패카드회 사 
에서 의 협 동준위 쏘프트웨 어재 리용프로그람에 대 해서 는 [ Griss , 1993] 에서 설명하였 다. 모 
토롤라에 서 의 두개 의 비 행 조종사연구에 대 하여 서 는 문헌 [ Joos , 1994] 에 서 제 시하였 다. 재 
리용의 관리 에 대 하여 서 도 문헌 [ Lim , 1998] 에 서 서 술하였 다. 재 리용과 관련 한 일 부 경 고 
는 문헌 [ Tracz , 1995] 에 서 주었 다. [Frakes and Fox , 1995] 는 재 리 용에 대 한 산업 적 인 태 도 
에 대 한 보고서 이 다. 객 체 검 색 과 재 리 용을 위 한 탐색 도식 에 대 해 서 는 문헌 [Isakowitz and 
Kauffman , 1996] 에서 서 술한다. Ada 재 리용실례연구에 대 해서 도 문헌 [ Skazinski , 1994] 에 서 
개 괄하였 다. 재 리용의 비 용에 대 한 효과성 은 문헌 [Barnes and Bollinger , 1991] 에 서 설 명 
하고 문헌 [Caldiera and Basili , 1991] 에 서 앞으로의 재 리 용을 위 한 구성 요소들을 확증하 
는 방법 들에 대 하여 설명하였 다. 문헌 [ Meyer , 1996 a ] 에서 는 객체 지향파라다임 이 재 리 용 
을 촉진한다는 주장을 분석하였다. 재리용과 객체기술과 관련된 4 개의 실례연구들은 문 
헌 [Fichman and Kemerer , 199 기 에 서 보여 주고 있 다. 문헌 [ Poulin , 199 刀에 서 재 리용척 도 
에 대 하여 론의하였 다. 문헌 [ Prieto - Diaz , 1993] 은 재 리용에 관한 상태보고서 이 다. 재 리 용 
에 관한 연구론문들은 IEEE 의 1994 년 9 월호에서 도 찾아 볼수 있 다. 쏘프트웨 어 

공학연구소에 서 진행한 구성 요소에 기 초한 쏘프트웨 어공학기 술에 관한 다양한 연구론문 
들은 문헌 [ Brown , 1996] 에 서 찾아 볼수 있 다. 구성 요소에 기 초한 쏘프트웨 어 공학기 술에 
관한 다른 론문들은 구성요소에 기초한 쏘프트웨 어시험 에 대 해서 론의하는 문헌 
[ Weyuker , 1998] 을 포함하여 IEEE Software 와 1998 년 9 월/ 10 월호에 있다. [ Bohrer , Johnson , 
Nilsson , and Rubin , 1998] 에 서 는 객 체 지 향적 업 무프로그람들을 위 한 구성 요소들에 대 하여 
설 명 하였 다. 문헌 [ Mili , Addy , Mili , and Yacoub , 1999] 에 서 는 재 리용을 공학학문으로 분 
석 하고 있 다. 문헌 [ Szyperski , 1998] 은 구성 요소지 향의 쏘프트웨 어 에 관한 정 보의 귀 중한 
문헌으로 되고 있다. 

틀거 리 에 관한 귀 중한 문헌은 [Lewis et al ., 1995] 이 다. 객체지 향적틀거 리 들의 재 리 용 
관리 에 대 해서는 문헌 [ Sparks , Benner , and Faris , 1996] 에서 설명 한다. 쏘프트웨 어를 구축 
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하기 위한 틀거 리 에 대 해서 는 문헌 [ Schmid , 1996] 에서 론의하였 다. 개 발자의 생산성 에 
주는 객 체지 향적 틀거 리의 영 향에 대 해서 는 [Moser and Nierstrasz , 1996] 에서 론의 하였 다. 
문헌 [ D’Souza and Wills , 1999] 에서도 객체지향적틀거리들과 구성요소에 기초한 개발방법 
들을 제 시 하였 다. Communications of the ACM ^\ 1997 년 10 월 호에 는 문헌 [ Johnson , 1997] 
을 비 롯하여 객 체지향틀거 리 들에 관한 수많은 기 사들이 있다. 틀거 리 에 관한 우수한 련 
속기 사들은 문헌 [Fayad and Johnson , 1999; Fayad and Schmidt , 1999; and Fayad , Schmidt , 
and Johnson , 1999] 에 서 찾아 볼수 있 다. Communications of the ACMS ] 2000 년 10 월 호에 는 
UML 을 리용하여 구성 요소들과 틀거 리 들을 모형화하는 방법 을 서 술한 문헌 [ Kobryn , 
2000] 을 비 롯하여 구성 요소에 기 초한 틀거 리 들에 대 한 기 사들이 들어 있다. 알렉 싼더 는 
구조의 문맥 안에서 설계패 턴을 제 기 하였 다 [Alexander et al ., 1997]. 패 런리 론의 기 원에 대 
하여 처 음으로 설명한것 은 문헌 [ Alexander , 1999] 이 였 다. 쏘프트웨 어 설 계 패 턴들에 관한 
주 요 한 문 헌 은 [ Gamma , Helm , Johnson , and Vlissides , 1995] 이 다 . 더 새 로 운 책 은 
[ Vlissides , 1998] 이다. [ Coad , 1992] 와 [ Fowler , 1997 a ] 에는 분석패턴들이 서술되여 있다. 문 
헌 [ Schmidt , 1995] 에서도 재 리 용가능한 객체지 향통신쏘프트웨 어를 개 발하기 위 하여 설 
계 패 런들이 리 용된데 대 하여 서 술한다. Communications of the ACMS \ 1996 년 10 월 호는 
설계패 턴들의 우월성 과 부족점 을 서 술한 문헌 [ Cline , 1996] 을 비 롯하여 패 턴들에 대 한 
많은 기 사들을 실 었 다. 패 런들과 구조들에 관한 소론문들은 IEEE Software 1997년 1월/2 
월호에서도 보게 된다. 이 러 한것 들로서 는 패 런언어들의 중요성 을 설명한 문헌 [Kerth and 
Cunningham , 199기과 구조들，패런들 그리고 객체들을 련결한 문헌 [ Monroe , Kompanek , 
Melton , and Garlan , 1997; Tepfenhart and Cusick , 1997; and Coplien , 199 刀을 들수 있다. 설 
계패턴들의 리용에 관한 또 다른 론문은 [ Cooper , 1998] 이다. 역패턴들에 대해서는 문헌 
[Brown et al , 1998] 에서 설명된다. 

쏘프트웨 어구성 방식 에 관한 정 보의 주요문헌은 [Shaw and Garlan , 1996] 이 다. 쏘프트 
웨 어 구성 방식 에 관한 기 사들은 IEEE Transactions on Software Engineering 1995 년 4 월호와 
IEEE Software 1995 년 11 월 호 특히 문헌 [ Shaw , 1995, and Garlan , Allen , and Ockerbloom , 
1995] 에서 찾아 볼수 있 다. 쏘프트웨 어구성 방식 들에 관한 더 새 로운 문헌으로서 는 [ Bass , 
Clements , and Kazman , 1988; Hofmeister , Nord , and Soni , 1999; and Bosch , 200 이 이 있다. 
쏘프트웨 어제 품개 발방향에 대 해서 도 문헌 [ Lai , Weiss , and Pamas , 1999; Jazayeri ; Ran , 
and van der Linden , 2000; and Donohoe , 200 이에 서 설명 하고 있 다. 

이 식 성 을 실현하는 전략들에 대 해서 도 문헌 [ Mooney , 1990] 에서 찾아 볼수 있 다. C 
와 UNIX 의 이 식 성 에 대 해서 는 문헌 [Johnson and Ritchie , 1978] 에서 론의 하였 다. Ada 제 품 
들의 이식성과 관련하여서는 문헌 [Nissen and Wallis , 1984] 를 참고하여야 한다. 

일반적으로 호상조작성과 특히 OLE , CORBA 그리고 ActiveX 에 대한 개괄을 알려면 
문헌 [ Adler , 1995] 를 참고하면 된다. 호상조작성에 대한 정보의 종합적 인 문헌은 [ Orfali , 
Harkey , and Edwards , 1996] 이 다. 미 들웨 어 에 대 한 개 괄은 문헌 [ Brown , 1999] 에 있 다. 
COM 은 문헌 [ Box , 1998] 에 서 설 명 하고 있 다. 자세 한 정 보는 마이 크로쏘프트회 사 홈폐 지 
www . microsoft . com 에 서 얻 을수 있 다. CORBA 에 대 하여 서 는 문헌 [Mowbray and Zahavi , 
1995] 에 서 자세 히 설 명 한다. 문헌 [ Leppinen , Pulkkinen , and Rautiainen , 199 刀은 Java 와 
CORBA 를 결 합하기 위 한 실 례 연구이 다. Communications of the 义 CM 1998년 10월 호에 는 
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문헌 [ Siegel , 1998] 을 비 롯하여 CORBA 에 관한 기 사들이 있다. Enterprise JavaBeans 에 대 
한 자세한 취 급은 문헌 [ Valesky , 1999] 에 서 주었 다. 


문 제 

8.1. 재 리용가능성, 이 식성，호상조작성 사이 를 자세 히 구분하시 오. 

8.2. 새 로운 제 품에 서 코드모둘은 변화되 지 않은 상태 에 서 재 리용된 다. 이 재 리용이 
어떤 방법들로 제품의 총체적 인 비용을 줄이는가? 비용은 어떤 방법들에서 변화되지 않 
는가? 

8 . 3 . 코드모둘이 한가지 변화 즉 더 하기연산에 서 덜 기연산으로 변화되 면서 재 리용된 
다고 가정 하자. 이 부차적 인 변화가 문제 8.2 의 비용절약에 영향을 미 치는가? 

8 . 4 . 재 리용가능성 에 주는 응집 도의 영 향은 무엇 인가? 

8 . 5 . 재 리용가능성 에 주는 결 합도의 영 향은 무엇 인가? 

8.6. 당신은 이제 다양한 오염조종제품들을 개발하는 큰 기업체에 가입하였다. 그 기 
업체는 9,500개의 각이한 FORTRAN 모둘들로 이루어 진 수백개의 쏘프트웨 어제품들을 가 
지고 있다. 당신은 앞으로의 제품들에서 이 모둘들을 가능한껏 재리용하기 위한계획을 
제 의하였 다. 당신의 제 안은 무엇 인가? 

8 . 7 . 자동서고순환체계를 생각해 보자. 모든 책들에는 막대부호가 있으며 빌리는 사 

탐들도 모두 막대부호코드가 있는 카드를 가지고 있다. 빌리러 오는 사람이 책을 빌릴 때 
사서는 책에 있는 막대부호들과 빌리러 온 사람의 카드를 자세히 조사하고 콤퓨터말단장 
치 에 C 를 입 력 한다. 그와 류사하게 책 을 바칠 때 다시 그것 을 자세 히 보고 사서 는 R 를 
입 력 한다. 사서들은 책들을 서 고에 보충해 넣거 나 서 고에서 없애 버 린다. 빌리는 사람들은 
말단장치 에 가서 특정한 저 자의 이 름을 가지 고 도서 관의 모든 책 들을 확정할수 있 으며 (빌 

리러온 사람이 A 를 입력하면 저자의 이름이 뒤따라 나온다.) 모든 책들은 특정한 제목 

( T 를 입 력하면 제 목이 나온다.)을 가지 고 확정하거 나 혹은 특정한 주제 로부터 모든 책 들을 
확정할수 있다 ( S 를 입 력하면 주제 가 뒤 따라 나온다.). 끝으로 만일 벌 리 려는 사람이 현재 
어떤 책을 빌리 고 싶으면 사서는 책을 바칠 때 그것을 요구한 사람을 위하여 보관하도록 
책에 표식을 할수 있다 (H 를 입력하면 책의 번호가 나온다.). 당신이 어떻게 재리용가능한 
모둘들에 대하여 높은 비률을 보장하겠는가를 설명하시오. 

8.8. 당신은 은행보고서 가 정 확한가를 결정 하기 위하여 제 품을 개 발해 줄것 을 부탁받 
았다. 필요한 자료는 월초의 잔고, 번호，날자，매개 행표의 량，매개 예금날자와 량，월말 
의 잔고들이 昏어 있다. 당신이 제품의 가능한껏 많은 모둘들이 앞으로의 제품들에서 재 
리용될수 있다는것 을 어 떻게 담보하겠는가 하는것 을 설명 하시 오. 

8.9. 금융기 관의 자동출납기 ( ATM ) 를 생 각해 보자. 사용자는 카드를 넣 고 4자리수자 
로 된 개 인식 별부호 ( HN ) 을 입 력한다. 만일 개 인식 별부호가 정 확하면 카드가 나온다. 그 
렇 지 않으면 사용자는 4개 의 서 로 다른 은행계 산서 에 대 한 다음의 조작들을 진 행할수 
있 다. 

(1) 일정한 량을 예 금하라. 날자, 예 금량 그리 고 계 산서번호를 보여 주는 령 수증 
을 인쇄한다. 
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(2) 20 딸라의 단위 로 200딸라까지 되찾으시 오(계 산서 는 찾아 가지 못할수도 있 
다.). 돈과 함께 사용자에게 날자, 되 찾아 간 량，계산서번호 그리고 돈을 찾 
아 간 다음 계산잔고를 보여 주는 령수증을 준다. 

(3) 계산잔고를 확정하시 오. 이것은 화면에 표시된다. 

(4) 두 계산서 들사이 에 자금을 옮겨 주시 오. 다시 자금이 옮겨 간 계산서 에 는 
돈을 지내 많이 찾아 가지 말도록 하여야 한다. 사용자에게 날자와 넘겨 준 
량 그리 고 두 계 산서번호들을 보여 주는 령 수증을 준다. 

(5) 끝내기. 카드가 나온다. 

제품이 가능한껏 많은 모둘을 앞으로의 제품들에서 재리용할수 있다는것을 어떻게 
담보하겠 는가를 설 명 하시 오. 

8.10. 개 발자들이 아란 5호 쏘프트웨어 에 있는 고장을 쏘프트웨 어생명주기 에서 어 떻 
게 일찌기 찾을수 있겠는가 (8.3.6)? 

8.11. 8.5.2 에는《1970년대의 레이손 COBOL 프로그람론리구조가 오늘날의 객체지향 
응용프로그람틀거 리의 고전적 인 조상이다.》라고 언급되 여 있다. 기술이 전에서 이것은 무 
엇을 의미하는가. 

8 . 12 . 그림 8-3 의 설계패턴에서 추상클라스들이 노는 역할을 설명하시오. 

8.13. 자동서고순환체계(문제 8.7) 가 가능한껏 이 식 가능하다는것 을 어떻 게 담보하겠는 
가를 설명하시오. 

8.14. 행보고서가 정확한가(문제 8.8) 하는것을 검사하는 제품이 가능한껏 이식가능하 
다는것을 어떻게 담보하겠는가를 설명하시오. 

8.15. 문제 8.9 의 금융기 관의 자동출납기 ( ATM ) 를 위 한 쏘프트웨 어 가 가능한껏 이 식 
가능하다는것 을 어 떻게 담보하겠는가를 설명 하시 오. 

8.16. 당신의 기 업체 는 암치 료에 쓰일 새 로운 형 태의 레 이자용 실시 간조종체 계 를 개 
발하고 있 다. 당신은 두개 의 아쌤 블리 어모둘들을 작성하는것 을 책 임지 고 있 다. 당신은 결 
과로 되는 코드가 가능한껏 이식가능하다는것을 담보하도록 어떻게 림을 지도하겠는가? 

8.17. 당신은 75만행 되는 COBOL 제품을 회사의 새 콤퓨터에 이식 할 책임을 지고 있 
다. 당신이 원천코드를 새 기계에 복사하고 그것을 콤파일하려고 노력하였지만 1만 5천 
개이상의 입출력명령문들가운데서 그 매개가 새로운 콤파일러가 처리할수 없는 비표준 
COBOL 문법으로 씌여 져 있다는것을 발견하였다. 이제 당신은 무엇을 하는가? 

8.18. (과정 안상 목표) 부록 1의 브로드렌즈지역 아동병 원제 품은 구조화파라다임 을 리 
용하여 개 발되 였 다고 가정 하자. 제 품의 어 느 부분이 앞으로의 제 품들에 서 재 리용될수 
있겠는가? 이제는 제품이 객체지 향파라다임을 리 용하여 개발되였다고 가정하자. 제품의 
어 느 부분이 앞으로의 제 품들에 서 재 리용될 수 있겠는가? 

8.19. (쏘프트웨 어공학독본) 교원은 문헌 [ Schricker , 200이의 복사본들을 나누어 줄것 
이 다. 지난 40년동안 COBOL 은 가장 널 리 쓰이 는 프로그람작성언어 로 되 여 왔다. 그 객 
체지향적 COBOL 이 다같이 어디서나 볼수 있을것이라고 생각하는가? 
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제 9 장. 계획작성과 타산ᅱ 


쏘프트웨어제품을 개발하는데서 나서는 난점들을 해결하는것은 쉬운 일이 아니다. 큰 
쏘프트웨어제품을 완성하는데는 시간과 자원이 요구된다. 다른 큰 프로젝트구성과 마찬가 
지로 프로젝트초기단계에서 주의깊게 계획을 작성하는것은 성공과 실패를 좌우하는 가장 
중요한 요인으로 된다. 이러한 초기의 계획작성은 결코 충분한것이 아니다. 시험과 마찬 
가지 로 계 획 작성 은 쏘프트웨 어 제 품개 발과 유지 정 비 과정 전반에 걸 쳐 계 속 진행 하여 야 한다. 
계획작성을 계속 진행하여야 하는데도 불구하고 이러한 활동들은 명세서를 작성한 다음 
즉시에 시작되며 설계에 들어 가기전에 계획작성이 진행되여야 한다. 공정의 이 시점에서 
개 발기 간과 비 용이 타산되 고 프로젝 트를 완성 하기 위 한 구체 적 인 계획 이 작성 된다. 

이장에서는 이러한 두가지 형태의 계획작성 즉 프로젝트전반에 걸쳐 진행되는 계획 
작성 과 일단 명세서 가 완성 된 다음에 수행 되여 야 하는 적 극적 인 계 획 작성 으로 나누어 고 
찰하도록 한다. 


9.1. 계획작성과 쏘프트웨어개발공정 

리 상 적 으로 개 발공정의 초시 기 에 전체 적 인 쏘프트웨 어 프로젝 트를 계 획 하고 목적 하 
는 쏘프트웨 어가 최종적으로 의뢰자에게 배포될 때까지 그 계획에 따라야 한다. 그러나 
이것은 초기 단계에서는 완전한 제품을 만들기 위한 계획을 작성하는데 필요한 정보가 
충분하지 못한데로부터 불가능하다. 실례로 요구사항확정 단계에서 그 어떤 계획작성(요 
구사항확정 단계 그자체를 위하여보다도 기 타 다른)을 하는것은 헛된 일이 다. 

개 발자들은 신속원형 을 작성하였고 (3.3) 의 뢰 자들은 신속원형 이 목적하는 제 품의 주 
요한 기능들을 포괄하고 있다는것을 인정했다고 하자. 이 단계에서는 그 제품을 위한 정 
확한 기간과 비용타산을 합리적 으로 할수 있을것 같다. 공교롭게도 그것은 맞지 않는다. 
요구사항확정단계의 마감과 명세작성단계의 마감에서 개 발자들의 처 분에 대 한 정보들사 
이 의 차이 는 륜곽적 으로 대 충설 계하는것 과 자세하게 설 계하는것 사이 의 차이 와 류사한것 
으로 볼수 있 다. 요구사항확정단계 의 마감까지 는 개 발자들은 기껏해 서 의 뢰 자들이 요구 
하는것을 비형식적으로 리해하게 된다. 이와 대비적으로 명세작성단계의 마감에 즉 의뢰 
자들이 구축하려 고 하는것 을 정 확히 서 술한 문서 에 수표를 하는 때 에 개 발자들은 목적하 
는 제 품의 모든 측면들을 자세하게 리해하게 된다. 이 것은 정 확한 개 발기 간과 비 용타산 
이 결정될수 있는 공정에서의 시작으로 된다. 

그럼에도 불구하고 일부 경우에 기업체들은 명세서가 작성되기전에 개발기간과 비용 


앞에서 설명한바와 같이 이 장에서 자료는 2개의 부분을 나란히 고찰한다. 9장에서의 
자료는 실례 연구 (11. 15과 12.8, 문제 11.20 과 문제 11.21) 의 쏘프트웨 어 프로젝 트관리 계 획과 과정 
안상 도달목표(문제 11.16) 를 위하여 요구된다. 
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타산을 진행할것을 요구한다. 극단한 경우에 의뢰자는 지어 신속원형 이 작성되기전에 한 
두시 간정도 예 비적 으로 론의를 진행한 기초우에서 값을 흥정한다. 그림 9-1 은 이것 이 무 
엇을 의미 하는가를 보여 주고 있다. 



主〒사니"]성 면괘작며 설계 섬혔 S 계 

(普석 > 

비용타산이 진행되는 단계 


.그림 9-1. 매 생명주기단계의 비용타산에 대한 상대적 인 범위의 모형평가 

문헌 [Boehm etal .， 200이에 있는 모형 에 기 초하여 생 명 주기 의 여 러 단계 들에서 요 
구되는 비용의 상대적인 범위를 보여 주고 있다. 실례로 어떤 제품이 통합단계의 마감에 
서 시험에 통과되여 의뢰자에게 배포되였을 때 그 비용이 백만딸라였다고 가정하자. 비 
용타산이 요구사항확정단계 에서는 도중에 있다고 하면 그것은 25만내지 4백 만딸라정 도의 
범위에 있게 될것이다. 류사하게 명세작성단계에서 비용타산이 도중에 진행된다고 하면 
50만내지 2백 만딸라정 도의 범위 로 줄어 들게 될것 이 다. 더우기 비 용타산이 명세작성단계 
의 마감에서 즉 가장 가능한 정확한 시기에 진행되였다고 하면 결과는 67만내지 150만딸 
라정 도의 범위 에 있게 될것 이 다. 달리말하면 비 용타산은 다음 절에서 그 리유를 밝히지 
만 정확히 과학적이지 못하다는것이다. 이 모형이 기초한 자료는 미공군전자체계에서 제 
기 한 5개 의 제 안 [ Devenny , 1976] 을 비 롯하여 낡은것 들이고 타산방법 은 그시 기 부터 개 선 
되기 시작하였다. 그럼에도 불구하고 그림 9-1 에 있는 곡선의 전반적인 형태는 아마 심 
하게 변화되지는 않는다. 결과적으로 기간과 비용을 때 이르게 타산하는것 다시말하여 명 
세서가 의뢰자들에 의해서 승인을 받기전에 타산을 진행하는것은 적합한 시기에 타산을 
진행하는것 보다 정 확도가 상당히 떨 어 진 다. 

이제 기간과 비용을 타산하는 방법들에 대하여 검토하기로 한다. 이 장의 나머지부 
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분들에 서는 명세 작성 단계 가 완료되 고 실제 적 인 타산과 계 획 작성 을 진행 할수 있게 되여 
있다고 가정한다. 


9.2. 기간과 비용의 타산 

예산은 쏘프트웨 어프로젝 트관리계 획 에서 필수불가결 한 부분이 다. 개 발을 시 작하기 전 
에 의뢰자는 제품을 개발하는데 얼마만한 비용이 드는가를 알려고 한다. 개발림이 실제의 
비용을 과소평 가하면 개 발자들은 프로젝트에 대 하여 돈을 잃게 될수 있다. 다른 한편 과 
대평 가하면 의뢰 자들은 비용 대 리득분석 이 나 투자에 대 한 보수에 기초하여 제품개발에서 
리익이 없다고 생각할수도 있다. 두 경우로 보아 정확하게 비용을 타산하는것이 중요하다 
는것이 명백하다. 

사실상 비용에는 두가지 형태가 있는데 그것은 쏘프트웨어개발과 관련된다. 하나는 
개발자들에 대한 비용으로서 내적인 비용(泊/ cos /) 이 있고 다른 하나는 의뢰자에 대 
한 비용으로서 외적인 ^{external cost)^>] 있 다. 내적인 비용은 프로젝트에 참가하는 개 
발림과 관리자，보장성원들의 로임과 그리고 제품개 발에 필요한 하드웨 어와 쏘프트웨 어 
의 비용，세금이나 리익，관리자들의 로임을 고려한 비용을 포함한다. 비록 외적인 비용 
이 일반적 으로 내적 인 비용에 순수 판매수익금을 더한것 이 라고 하더 라도 일부 경우에는 
경제적인 요인과 심리적인 요인이 중요하다. 실례로 열심히 일할것을 요구하는 개발자들 
에게 의뢰자들은 내적인 비용보다 적은 비용을 보상하려고 할수 있다. 값이 설정된 기초 
우에서 계 약이 맺 어 질 때는 사정 이 다르다. 의뢰 자들은 결과적 인 제품의 품질이 혹시 
더 떨어 지게 될수 있는 경우를 고려하여 설정된 기타 다른 가격설정보다 더 낮게 가격 
설정하는것 을 거 절할수도 있다. 따라서 개발림 은 설정 된 값을 약간 올리 면서 도 다른 경 
쟁자들이 설정 했 다고 보아지 는 가격 보다는 좀더 낮게 값을 설정할수 있 다. 

계획에서 또 다른 하나의 중요한 부분은 프로젝트의 개발기간에 대한 타산이다. 의 
뢰자는 확실히 완성된 제품이 배포될 시기를 알고 싶어한다. 만약 개발림이 그러한 일정 
계획을 가지고 있지 않으면 좋게는 기업체가 신용을 잃게 되며 나쁘게는 벌금이 적용된 
다. 모든 경우에 쏘프트웨어프로젝트관리계획에 책임이 있는 관리자는 해야 할것들에 대 
하여 많은 설명을 해야 한다. 반대로 개발기업체가 제품을 개발하는데 요구되는 시간을 
과대평가하면 의뢰자들이 다른 기업체로 찾아 가게 된다. 

유감스럽게도 비용이나 기간에 대한 요구를 정확히 타산하는것은 결코 쉽지 않다. 
비 용이 나 기 간을 정 확히 타산하는데는 아주 많은 요인들이 있 다. 중요한 요인의 하나는 
인적 요인이 다. 30여년전에 쌔 크맨 ( Sackman ) 과 그의 동업 자들은 프로그람작성 자들사이 에 
28에서 1 까지의 차이 가 있다는것을 발견하였다 [ Sackman , Erikaon , and Grant , 1968]. 경 
험 있는 프로그람작성 자가 새 로 시 작한 프로그람작성 자보다 항상 더 먼저 일 을 수행한다 
고 말함으로써 그들의 결과를 쉽게 거절해 버 릴수 있지만 쌔크맨과 그의 동료들은 조화 
가 맞는 여러 쌍의 프로그람작성자들을 비교하였다. 실례로 그들은 류사한 류형의 프로 
젝트에 대하여 …년간의 경험을 가진 두명의 프로그람작성자를 관찰하고 그들이 코드작 
성 과 오유수정 과 갈은 과제 를 수행하는 시 간을 측정해 보았다. 그다음에 는 짧은기 간에 
전문가수준에 오르고 류사한 교육학적인 배경을 가진 두명의 프로그람작성 자들을 관찰해 

276 



보았다. 성 능상 좋고 나쁨을 비 교하여 제품의 크기 에서는 6부터 1까지，제품의 실행시 간 
에서는 8에서 1까지，개발시간에서는 9에서 1까지，코드작성시간에서는 18에서 1까지， 
오유수정시간에서는 28에서 1까지 차이가 있다는것을 관측하였다. 특히 놀라운것은 11년 
의 경험을 가진 두명의 프로그람작성자들에게서도 하나의 제품에 대한 성능상 좋고 나쁨 
이 있다는것이다. 지어 쌔크맨의 실례에서 좋고 나른 경우를 제쳐 놓고서도 관측된 차이 
는 5에서 1까지에 있었다. 이러한 결과들에 기초하여 명백히 비용과 시간을 임의의 정확 
도로 타산할수 있 다는것은 기 대할수 없다. 큰 프로젝 트에 대 하여서 는 개 별적 인 사람들속 
에서의 차이가 무시되는 경향이 있다고 주장하는것도 있지만 이것은 아마도 우리가 바라 
던것 이 다. 즉 하나 또는 두개 의 아주 훌륭한(또는 아주 나른) 개발림 성 원들이 있 다고 해 
도 일정계획에서 뚜렷한 차이가 있게 되고 예산에 대해서도 결정적인 영향을 준다. 

타산에 영향을 줄수 있는 또 하나의 인적요인은 많은 나라들에서 프로젝트개발기간 
에 결정적인 역할을 하는 성원들이 사직하지 않을것이라는것을 담보하지 못한다는것이다. 
그때 사직한 자리를 채우고 림에서 교체를 진행하거나 혹은 남아 있는 성원들이 잃은것 
을 보상해 야 한다는것 을 인식하는데는 많은 시 간과 비 용이 든다. 두 경 우에 다 일정 계 획 
을 잘못 세우고 타산이 잘못 진행되였다. 

비 용타산문제 에 대 하여서는 또 다른 문제 가 있다. 즉 제품의 크기를 어떻게 측정하 
겠는가 하는것 이 다. 


9. 2. 1 . 제품의 크기에 대한 척도 

제품의 크기 에 대 한 가장 일반적 인 척도는 코드의 행수를 리용하여 계 량하는것 이 다. 
일반적으로 두개의 서로 다른 단위들이 리용된다. 즉 코드의 행들 ( LDC ) 과 배포된 천개 
의 원천명령 ( KDSI ) 을 리용한다. 많은 문제들이 코드의 행수와 관련되여 있다 [vander 
Poel and Schach , 1983]. 

1 . 원천코드를 작성하는것 은 전체 적 인 쏘프트웨 어개 발노력 의 적 은 부분에 지 나지 
않는다. 원형 을 작성 하고 명세 를 작성하며 계 획 작성，설계, 실현，통합，시 험하는 
데 요구되는 시간은 모두 마지막에 완성된 제품의 원천코드행수의 함수로 표현 
할수 있다고 하는것은 어딘가 다소 흥미 있는 문제로 될것 같다. 

2. 갈은 제품을 두개의 서로 다른 언어로 실현하면 코드의 행수가 서로 다르게 된다. 
또한 Lisp 와 갈은 언어 들이나 혹은 많은 비 수속형 4 GL 들을 리 용하여 코드작성하면 
코드의 행수에 관한 개념을 정의할수 없다. 

3. 흔히 코드의 행수를 어떻게 계산하는가는 정확히 밝혀 지지 않는다. 다만 실행 
할수 있는 코드의 행만을 계산할수 있는가 혹은 자료의 정의도 계산할수 있는가? 
그리고 설명문은 계산할수 있는가? 계산할수 없다면 프로그람작성자들이 《비생 
산적》이 라고 여기 는 설명 문들에 시 간을 랑비 하는것 이 혐 오스럽다고 할수 있는 
데 이 것은 위 험하다. 그러 나 설명 문들이 계산되 면 프로그람작성 자들이 자기 들의 
생산성 을 올리 려는 시도에서 설명문들을 속여 가며 쓰는것도 상반되는 위험으로 
된다. 또한 일감조종언어명령문들을 계산하는데 대해서는 어떻게 생각하는가? 또 
하나의 문제는 성능을 개선하려고 제품을 보강하고 때로는 코드의 행수를 줄이는 
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과정에 변화된 행수나 삭제된 행수들을 어떻게 계산하는가 하는것이다. 코드의 
재 리용 (8.1) 은 또한 행 의 계 산을 포함하고 있 다. 즉 만일 재 리용된 코드가 수정 되 
면 그것을 어떻게 계산하는가? 또한 만일 코드가 어미콜라스로부터 계승되면 (7.8) 
어떻게 계산하는가? 간단히 말하여 정확하면서도 간단한 코드행수의 척도는 바로 
무엇이나 다 간단히 세는것 이 다. 

4. 작성된 모든 코드들이 의뢰자에게 배포되지는 않는다. 코드의 절반정도가 개발 
노력 을 지 원하는데 필 요한 도구들로 구성되 여 있는것 이 보통이 다. 

5. 쏘프트웨 어개 발자들이 보고서생 성프로그람이 나 화면생 성프로그람 혹은 도형사용 
자대 면부 ( GUI ) 생 성프로그람과 같은 코드생 성프로그람들을 리용한다고 가정 하자. 
개 발자의 일 부가 설 계활동을 몇분정 도 진행한 다음 도구들에 의하여 수천행되 는 
코드가 생성된다. 

6. 일 단 제품이 완전히 완성될 때 만 완성된 제품에 들어 있는 코드의 행수를 결정할 
수 있다. 그러 므로 코드의 행 수에 기 초하여 비 용타산을 하는것 은 의 심할바없 이 
위 험한것 이 다. 평 가공정 을 시 작하자면 완성 된 제 품에 있는 코드의 행 수를 평 가하 
여 야 한다. 그다음 이 평 가결 과는 제 품의 비 용을 계 산하는데 리용한다. 모든 비 
용타산수법들에는 불확정성 이 있을뿐만아니 라 불확정적 인 비 용타산 그자체 에 대 
한 입 력 자료가 불확실 하면 즉 아직 채완성 되 지 않은 제 품에 들어 있는 코드의 행 
수가 입 력 되 면 그때 에 는 비 용 타산결 과에 대 한 믿 음성 이 높지 않을수 있 다. 

코드의 행수는 이처럼 믿을수 없기때문에 다른 척도를 고찰하여야 한다. 이른바 쏘 
프트웨 어 과학 [ Halstead , 197刀에 서 는 제 품크기 에 대 한 여 러 가지 측정 방법 들을 제 시 하고 
있 다. 이 것 들은 쏘프트웨어 과학의 기 본적 인 척 도, 즉 쏘프트웨어제 품에 있는 연산과 연 
산자의 수，특정한 연산과 특정한 연산자의 수로부터 결과를 엄 을수 있 다. 코드의 행 으 
로 계산하던 방법과 마찬가지로 제품이 일단 완성된 다음에만 이와 같은 계산을 할수 있 
으며 따라서 척도에서 예측능력이 크게 감소된다. 또한 많은 연구들은 쏘프트웨어과학의 
타당성에 대하여 의심을 해소하여 주고 있다 [ Shepperd , 1988 a ； Weyuker , 1988 b ； Shepperd 
and Ince , 1994]. 

제 품의 크기 를 평 가하는 또 다른 연구방법 은 쏘프트웨 어개 발공정 에 서 신속하게 결 정 
할수 있는 측정 가능한 량들에 기 초한 척 도를 리용하는것 이 다. 실례 로 반더 포웰 (van der 
Poel ) 과 스캐 취 ( Schach ) 는 중간정 도규모의 자료처 리 제 품 즉 2〜10명 이 1 년동안에 완성 할 
수 있는 제 품에 대 한 비 용타산을 진행 하기 위 하여 FFP 척 도를 제 기 하였 다 [van der Poel 
and Schach , 1983]. 자료처 리 제품에서 세가지 기초적 인 구조적요소들은 그것의 파일 ( File ), 
흐름 ( Flow ), 처리 ( Process ) 들이 다. 즉 FFP 라는 이름은 이러한 요소들의 첫 문자들로 이루 
어 진 략어 이다. 파일은 제품에 항구적으로 들어 있는 물리적으로 또는 물리적으로 련관 
된 기록들의 집합으로서 정의된다. 즉 트랜잭션과 림시적인 파일들은 제외된다. 흐름은 
화면이 나 보고서 와 같이 제 품과 주위 환경사이의 자료대 면부이다. 처 리는 자료들에 대 한 
론리적 인 또는 산수적인 조작으로 정의된다. 즉 실례로 처 리는 정돈이 나 타당성검증，갱 
신들을 포함하고 있다. 파일의 수는 Fi , 흐름의 수는 FI , 처리의 수는 TV 라고 하고 제품 
에서 그 크기를 S , 비용은 C ■라고 하면 다음과 같이 계산할수 있다. 즉 


278 


S = Fi + FI + Pr 


(9.1) 




c - d x S (9.2) 

여 기서 d 는 기 업체들에 따라서 변화되 는 상수이다. 상수 d 는 해 당한 기 업체안에서 
쏘프트웨 어개 발공정 의 효과성 (생 산성 )에 대 한 측정 값이다. 제 품의 크기 는 간단히 파일과 
흐름，처리의 개수들의 합으로 되며 일단 구성방식설계가 완성되면 결정될수 있는 량이 
다. 비 용은 제 품의 크기 에 비 례하며 비 례상수 c / 는 해 당 기 업체 에서 이 미 개 발한 제 품과 
관련한 비 용자료에 적 합한 최 소두제 곱에 의하여 결정 된다. 코드의 행수에 기 초한 척 도와 
는 달리 비 용은 코드작성 시작전에 타산될 수 있 다. 

FFP 척 도의 타당성 과 믿음성 은 중간규모의 자료처 리응용프로그람의 범위내 에 있는 
목적하는 실 례프로그람을 리용하여 보여 줄수 있 다. 유감스럽 게 도 척 도는 자료기 지 즉 
많은 자료처리제품의 본질적인 구성요소들에는 절대로 확장되지 못한다，독립적으로 개 
발한 제품의 크기 에 대한 척도는 기능점들에 기초하여 엘브레취트 ( Albrecht ) 가 개 발하였 
다 [ Albrecht , 1979]. 엘 브레 취 트의 척 도는 입 력 항목들의 수 Inp , 출력 항목들의 수 Out , 요 
구수 /쌔，주파일의 今 Maf , 대면부의 수 /«/에 기초하고 있다. 가장 간단한 방법 으로서 
기능점들의 수 FP 는 다음의 식 

FP = 4 x Inp + 5 x Out + 4 x Inq + 10 x Maf + 7 x Inf (9.3) 

에 의해서 계산된다. 이것은 제품의 크기 에 대 한 척도이기때 문에 비용타산과 생산성평 가 
에 리용될 수 있 다. 

식 (9.3) 은 세단계의 계산으로 간단히 진행된다. 첫째로，조절되지 않은 기능점들이 
계산된다. 

1. 제 품의 매 개 구성 요소들 Inp , Out , Inq , Maf , Inf 들은 단순한것 , 보통인것 , 복잡 
한것으로 분류되여야 한다(그림 9-2 를 보시오). 


구성요소 


복잡성의 준위 


간단한 상태 

중간상태 

복잡한 상태 

입력항목 

3 

4 

6 

출력 항목 

4 

5 

7 

요구 

3 

4 

6 

주파일 

7 

10 

15 

대면부 

5 

7 

10 


그림 9-2. 기능점값표 


2. 매개 구성요소들은 그 준위에 따라 많은 기능점들에 부가된다. 실례로 보통의 
입 력값은 식 (9.3) 에 반영된바와 같이 네개의 기능점 들에 부여된다. 그러 나 단순 
한 입 력값은 오직 세개 이 고 반면 에 복잡한 입 력 값은 6개 의 기 능점 들에 부가된 다. 
이 단계에서 요구되는 자료들은 그림 9-2 에 보여 준다. 

3. 매개 구성요소들로 부여된 기능점들은 그다음 합하여 조절이 되지 않은 기능점 
( L / PP ) 을 부여한다. 
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둘째 로, 기술적 인 복잡성 인자 ( rao 가 계산된다. 


1 

자료통신 

2 

분산자료처 리 

3 

성능척도 

4 

중요한 하드웨 어 

5 

높은 트랜잭션비률 

6 

직결자료입력점 

7 

말단사용자의 효과성 

8 

직결갱신 

9 

복잡한 계산 

10 

재리용가능성 

11 

쉬운 설치 

12 

쉬운 조작 

13 

이 식 가능성 

14 

유지 정 비 성 


그림 9-3. 기능점계산의 기술적요인 

이것은 14개의 기술적 인 요인들의 효과에 대한 측정 이다. 기술적 인 요인들에는 높은 
트랜잭 션비률，성 능기 준(실례 로 처 리 능력 혹은 응답시 간)，직 결갱 신 등이 있으며 완전한 
요인들을 그림 9-3 에 보여 준다. 이러한 매 14개의 요인들은 0( 《없거나 영향이 없다.》)부 
터 5( 《 전 반에 걸 쳐 강하게 영 향을 준다.》)까지 에 서 값을 부여한다. 결 과 14개 의 수를 합 
하여 전체 적 인 영 향정 도 ( DI ) 를 엄 는다. TCF 는 그다음 다음의 식 에 의하여 계 산된 다. 즉 

TCF = 0.65 + 0.01 x DI (9.4) 

이가 0〜70까지 변화될수 있기때문에 TCF 는 0.65 〜 1.35 사이에서 변할수 있다. 

셋째로, 기능점의 수 FP 는 다음과 같이 계산된다. 

FP = UFP x TCF (9.5) 

쏘프트웨 어생 산능률을 계 산하기 위한 실험 을 진행한데 의하면 KDSI 를 리용하는것보 

다 기 능점 들을 리용하는것 이 더 좋다는것 을 보여 주었 다. 실례 로 죠네 스 ( Jones ) 는 KDSI 

를 계산하면서 800%를 초과하는 결함을 발견하였지만 기능점을 계산할 때에는 겨우 
200%만을 발견하였 다고 지 적하였 다 [ Jones , 1997]. 

이 결과는 매우 훌륭하다. 

코드행 에 비한 기 능점 의 우월성 을 보여 주기 위하여 죠네 스는 그림 9-4 에 실례 를 보 

여 주었 다 [ Jones , 1997]. 같은 제 품을 아쌤 블리 어 와 Ada 로 코드작성 하여 결 과를 비 교하였 

다. 우선 월공수당 KDSI 를 고찰하여 보자. 이 척도는 아쌤 블리 어에서의 코드작성 이 얼 
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핏 보기 에는 Ada 에서의 코드작성보다 60% 더 효률적 이 라는것을 보여 준것 같지만 이것 
은 명백 히 잘못된 결론이 다. Ada 와 갈은 3세대언어들은 단지 3세 대언어 로 코드작성하는 
것 이 훨씬 더 효과적 이 라는 사정 으로 하여 아쌤 블리 어대 신에 리용하고 있다. 이 번에는 
두번째 척도인 원천명령문당 비용을 고찰하여 보자. 이 제품에서 하나의 Ada 명령문은 
2. 8개의 아쎔블리어명령과 동등하다는것을 생각해 보시오. 효과성의 크기로서 원천명령 
문당 비 용을 리 용하면 Ada 보다 아쌤 블리어 로 코드작성하는것 이 더 효과적 이 라는것 을 알 
수 있 다. 그러 나 월 공수당 기 능점 을 프로그람작성효과성 의 척 도로 취 하는 경 우 아쌤 블리 
어 에 비한 Ada 의 우월성 이 명백 히 알려 진다. 



아쌤블리어판본 

Ada 판본 

원천 코드크기 

70 KDSI 

25 KDSI 

개발비용 

1,043,000딸라 

590,000딸라 

월 공수당 KDSI 

0.335 

0.211 

원천명령당 비용 

14.90 딸라 

23.60 딸라 

월공수당 기능점 

1.65 

2.92 

기능점당 비용 

3,023 딸라 

1,170딸라 


그림 9-4. 아쌤 블리 어 제 품과 Ada 제 품의 비 교 [ Jones , 1987]. [01987 IEEE .] 


다른 한편 기능점뿐만아니 라 식 (9.1) 과 (9.2) 의 FFP 척도는 이와 같은 약점을 가지고 
있다. 즉 제품의 유지정비가 종종 부정확하게 계산된다. 하나의 제품을 유지정 비하자면 
그 제품에 큰 변화를 줄 때 파일，흐름，처리의 수 또는 입력，출력，요구，주파일，대 
면부의 수가 변화되지 말아야 한다. 이러한 견지에서 코드의 행들을 고려하는것은 더 좋 
은것 이 아니 다. 최 악인 경 우에 매 개 행 들을 코드행 의 총 수를 변화시키 지 않는 상태 에 서 
완전히 다른 행 으로 교체하는것 이 가능하다. 

엘 브레 취 트의 기 능점 에 대 한 확장으로서 최 소한 40개 의 변종이 제 기 되 였 다 [Maxwell 
and Forselius , 2000]. 조절 되 지 않은 ^1 (unadjusted function points , UFP ) 을 계 산하기 위 
한 보다 좋은 방법 을 찾기 위 하여 씨 몬스 ( Symons ) 는 MK II 기 능점 을 제 시 하였 다 [ Symons , 
1991]. 쏘프트웨어를 매개가 입력，처리，출력으로 이루어 진 구성요소트랜잭션모임으로 
분해한다. 그다음 입력，처리，출력으로부터 t/，P 값을 계산한다. MK II 기능점들은 세계 
적 으로 널 리 리용되 고 있 다 [ Boehm , 1997]. 

9. 2. 2. 비용타산방법 

크기를 평가하는데 난점이 있음에도 불구하고 개발자들이 평가에 영향을 줄수 있는 
많은 요인들을 가능한껏 고려하면서 프로젝트의 기간과 프로젝트의 비용을 정확히 계산 
하기 위하여 할수 있는 모든것을 다 하는것이 중요하다. 평가에 영향을 줄수 있는 요인 
들에는 인간의 기능수준，제품의 복잡성，제품의 크기(비용은 크기에 따라 증가한다.)， 
응용분야에 대 한 개발림 의 파악，그 제 품에 적 용될 하드웨 어， CASE 도구를 쓸수 있는가 
하는것들이 포함된다. 다른 하나의 요인은 이른바 최종기한이 주는 영향이다. 만일 제품 
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이 어느 때까지 완성되여야 한다면 월공수는 마감기한이 주어 지지 않을 때보다 더 크다. 

모든 정황을 다 포괄했다고는 볼수 없는 우의 목록만 보아도 평가가 힘든 문제이라 
는것을 명백하게 알수 있다. 여 러가지 방법을 적용하여 보았는데 성공여부는 각이하다. 

1. 류추에 의한 전문가평가 이 기법에서는 많은 전문가들을 객체로 하고 있다. 전문 
가는 목적 하는 제품과 자기 가 적극 참여하여 완성한 제품을 비교하여 류사한 점과 차이 
점을 알아 내는 방법으로 평가를 내릴수 있다. 실례로 전문가는 직결자료식별능력을 가 
져야할 목적하는 제품을 묶음방식으로 자료를 넣어주는 2년전에 개발한 류사한 제품과 
비 교할수 있 다. 개발림 이 개 발하여 야 할 제 품의 류형 을 잘 알고 있기때 문에 전문가는 개 
발기한과 노력 을 15%줄일 수 있 었다. 그러 나 도형사용자대 면부 ( GUI ) 는 아주 복잡하다. 
즉 이것은 시 간과 노력 을 25%나 증대시 킨다. 종합적 으로 말하면 목적하는 제 품은 대부 
분이 개발림성 원들이 잘 알지 못하는 언어 로 개 발하는 경 우 기 간은 15%, 노력 은 25% 
늘어 난다. 이 세 가지 수자를 종합하면서 전문가는 목적하는 제 품이 이 전의 것 보다는 시 
간이 25%, 노력은 30% 더 들것이라고 판단하게 된다. 이전의 제품이 완성되는데 12개 
월의 시 간과 100명 이 1개 월동안 진행하는 토력 이 든다면 목적하는 제 품은 15개 월의 시 간 
과 130명 이 1개 월동안 진행하는 토력 이 요구될것 이 다. 

그 기업체에 있는 다른 두 전문가는 갈은 두 제품을 비교하였다. 

한 사람은 최 종제 품개 발에 13. 5개 월의 시 간과 140명 이 1개 월동안 진행하는 토력 이 
들것 이 라고 보았다. 다른 사람은 16개 월의 시 간과 95명 이 1개 월동안 진행하는 토력 이 든 
다고 보았다. 이 세 사람의 예측을 어떻게 조정하겠는가? 한가지 방법은 델피 ( Delphi ) 기 
법 이 다. 이 기 법은 기 업체협의회 를 가지지 않고도 결론에 도달할수 있게 해 준다. 그것은 
집단을 움직일수 있는 설득력을 가진 사람이 한명이라도 있으면 좋지 않은 부작용을 초 
래 할수 있 다. 이 기 술을 도입할 때 전문가들은 독자적 으로 사업한다. 각자는 자기 식 의 
평가를 진행하고 그 평가에 대한 근거를 밝힌다. 그다음 이러한 평가와 근거들을 전문가 
들에 게 배 포한다. 그러 면 이 번에 는 모든 전문가들이 두번째 평 가를 진행한다. 전문가들 
이 하나의 공통적 인 평 가를 내릴 때까지 이 러한 평 가와 배포작업을 계속 진행한다. 이 러 
한 반복과정 기 간에 는 기 업 체 협 의 회 를 진 행 하지 않는다. 

실 지 부동산의 가치 는 류추를 리용한 전문가적평 가에 기 초하여 결 정한다. 평 가자는 
어느 한집을 최근에 팔린 류사한 집과 비교하는 방법으로 그 가치를 결정하게 된다. A 
라는 집 의 값을 결정하려 고 하는데 B 라는 옆집 은 205,000딸라에 금방 팔리웠고 이 웃거 리 
에 있는 집 C 는 석달전에 218,000딸라에 팔리 웠 다고 가정 하자. 

이 런 경 우에 평 가자는 다음과 같이 추리할수 있다. 즉 집 A 는 집 B 보다 침실 이 하 
나 더 많고 마당은 5,000평 방피트 더 크다. 집 C 는 집 A 와 크기 가 거의 비슷하지만 지 
붕상태 는 한심하다. 한편 집 C 에 는 목욕탕용분사식물흐름장치 가 있 다. 주의 깊게 타산해 
본 평 가자는 집 A 의 값을 215,000딸라로 결정할수 있 다. 

쏘프트웨어 제품인 경 우 류추를 리용한 전문가평 가는 실지 부동산가치 타산보다 정 
확하지 못하다. 첫번째로 쏘프트웨어전문가가 파악이 없는 언어를 리용하는 경우 시간 
은 15%, 노력 은 20%로 늘어 날것 이라는데 대 하여 상기해 보아야 한다. 전문가에 게 매 
개 의 차이 로 하여 초래할수 있는 영 향을 예 견할수 있게 하는 실 용성 있는 자료가 주어 
지 지 않은 경 우에 는 추측 이 라고밖에 달리 는 생 각할수 없 는 그러한 오유로 하여 정 확 
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하지 못한 비용타산을 하게 된다. 게다가 전문가가 모든것을 기억해 낼수 없다면(또는 
상세한 기록을 해놓치 않았다면) 완성된 제품들에 대한 기억은 부정확할수밖에 없다. 
총체적으로 전문가는 인간이므로 정확한 예측을 할수 없다는 견해도 있다. 동시에 한 
전문가기업체에 의한 평가결과는 그들의 집체적인 경험을 반영하는것으로 된다. 즉 만 
일 이러한 경험이 실지로 포괄적인것이라고 하면 결과는 정확한것으로 된다. 

2. 상승식방법 어떤 제품자체의 가격을 타산하는데서 발생하는 오유를 극복하는 한 
가지 방도는 그 제품을 보다 작은 구성부분들로 분할하는것 이 다. 그리 고 그 매 구성부분 
들의 개발기간과 비용을 계산하고 그 값을 합하는 방법으로 전체 가격을 계산한다. 이 
방법은 보다 작은 구성부분들에 대한 비용타산이 일반적으로 전체에 대하여 진행하는 계 
산보다 더 빠르고 정확하다는 우점을 가지고 있다. 또한 평가과정 이 보다 더 세부적 이 라 
는것 이다. 이 방법의 약점은 제품값이 그 구성부분들의 값들을 합한것보다 크다는것 이 다. 

객체지향파라다임과 관련하여 여러가지 클라스들의 독립성은 상승식방법을 도와 주 
고 있다. 그러나 제품에 있는 여러가지 객체들속에서 있게 되는 호상작용은 평가과정을 
복잡하게 한다. 

3. 알고리듬적인 비용타산모형 이 방법에서는 기능점이나 FFP 와 갈은 척도가 제품의 
비용을 결정하기 위한 어느 한 모형에 입력자료로 리용된다. 타산자는 척도값을 계산한 
다. 즉 기 간과 비 용타산은 그 모형 을 리용하여 계 산된 다. 표면 상 알고리 듬적 인 비 용타산 
모형은 전문가들의 의견에 비하여 우월하다. 왜냐하면 전문가는 우에서도 언급한바와 같 
이 편차가 있으며 완성된 제품과 목적하는 제품의 일부 측면들을 스쳐 지나갈수 있기때 
문이 다. 이와 달리 알고리듬적인 비용타산모형은 편차가 없다. 즉 매 제품이 같은 방법 
으로 처 리된다. 이 모형 을 리용할 때의 위 험은 그 타산이 기 초적 인 추측에 불과하다는것 
이 다. 실례 로 기 능점모형 이 기 초로 하고 있는것 은 제 품의 매 측면 이 식 (9.3) 의 오른쪽 
에 있는 다섯개의 량들과 14개 의 기 술적 요인들에 구현되 여 있다고 하는 추측이라는것 이 
다. 그다음의 문제 점 은 모형 의 파라메터 들에 어 떤 값을 부여 하겠는가 하는데 주관적 인 
판단이 중요하게 요구된다는것 이 다. 실례 로 기 능점모형의 특정한 기 술적 인 요인이 3에 
비 례하겠는지 아니 면 4에 비 례하겠는지 명 백하지 않을 때 가 많다. 

알고리듬적 인 비 용타산모형들은 많이 제기되 였다. 어떤 모형들은 쏘프트웨어가 
어떻게 개발되는가 하는것과 관련한 수학적리론들에 기초하고 있다. 다른 모형들은 
통계 학적인 리 론에 기 초하고 있다. 즉 많은 프로젝 트들이 연구되 고 그러한 자료로부터 
경 험적 인 규칙 들이 확립된다. 혼성모형 은 수학적 인 식들과 통계 적 인 모형 그리 고 전 
문가적 인 판단을 통합하고 있다. 가장 중요한 혼성모형 은 보엠 ( Boehm ) 의 COCOMO 로 
서 이 에 대 하여 서 는 다음절 에 서 상세 히 설 명한다(준말 COCOMO 에 대 하여 서 는 다음의 
《 알고 싶은 문제》를 보시 오.). 


알고 싶© ©제 

COCOMO 는 Constructive COst MOdel 에서 매 단어의 첫 두 글자를 따서 만든 큰말이 
다. 인디 아의 KoKomo 와 그 어떤 관련이 있는 소리 같은 말이 다. COCOMO 모형 이 i ■는 표 
현은 쓰지 말아야 한다. ■즉' COCOMO 에 서 《 MO 》 는《 모형》을 의 미한다. 
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9. 2. 3. 중간 COCOMO 

COCOMO 는 실제상 전체적인 제품을 취급하는 거시적인 타산모형으로부터 제품을 
세부적으로 취급하는 미시적인 타산모형에 이르기까지 세가지 모형들의 련속이다. 이 절 
에 서 는 중간 COCOMO 에 대 한 설 명 을 주고 있 으며 이 것 은 복잡한것 과 세 부적 인것 에 대 
하여 중간준위 를 가진 다는것 을 의 미 한다. COCOMO 는 문헌 [ Boehm , 1981] 에 서 상세 히 
서술하였다. 즉 문헌 [ Boehm , 1984 b ] 에서는 그것에 대 한 개관을 주었다. 

중간 COCOMO 를 리용하여 개 발기 간을 타산하는것은 두 단계 로 진행한다. 첫째 로, 
개 발노력 에 대 한 대 략적 인 평 가가 주어 진다. 여 기서는 두개의 파라메터들이 평 가되 여 야 
한다. KDSI 로 계산된 제품의 크기와 제품개 발방식 그리 고 그 제품들을 개 발하는 난관의 
내부준위에 대한 측정이 평가되여야 한다. 여기에는 세가지 방식 즉 작고 간단한 단순한 
방식 ( orgam ’ c )， 크기 가 중간정 도인 중간방식 복잡한 방식 (embedded, complex) 

이 있다. 

이 두 파라메 터 들로부터 명 목상의 토력 ( wwn ' m ?/ 을 계 산할수 있다. 실례 로 만 
일 프로젝트가 본질에 있어서 단순한것으로 판명되면 명목상 토력은 다음의 식으로 계산 
된다. 즉 


명목상 로력 = 3.2 x ( KDSI ) 105 월공수 (9 .句 

3.2 와 1.05 는 중간 COCOMO 를 개 발하기 위 하여 보엠 이 리 용한 단순한 방식 의 제 품 
에 대한 자료에 가장 적합한 값들이다. 실례로 만일 개발될 제품이 단순하고 12,000개의 
원천명 령 문들 (12 KDSI ) 로 평 가된다면 명목상 토력 은 다음과 같이 계산된다. 즉 
3.2 x (12) 1 •현 = 월공수 

(그러 나 이 값에 대한 해설을 보려면 다음의 《알고 싶은 문제》를 보시오). 


알:2 싶 e ©제 

명목상 토력의 값에 대한 한가지 반응은《만일 매 43명의 사람들이 1개월동 ( ■ 진행 
하는 로력(월공수)이 12,000개의 원천명 령문들을 작성하는데 요구되 였다면 평균 ᄆ 프로 
그람작성 자는 1개 월동안에 300개 행보다 더 적은 코드를 작성한것 으로 된다.》 

300행되는 제품은 바로 코드의 행수가 300행이라는것을 의미한다. 대비적 으 j . 유지 
정비가능한 12,000행되는 제품은 생명주기의 모든 단계들을 다 거쳐야 한다. 다ᅳ 말하 
여 43명 이 1개 월동안 진행하는 전체 토력 은 코드작성 을 비 롯하여 많은 작업 들사 포함 
하게 된다. 그림 1-2 의 파라다임도표에서 보여 준것처럼 모듈의 코드작성은 평균 총 개 
발토력의 15%정도밖에 되지 않는다. 


다음으로 이러한 명목상 토력은 15개의 쏘프트웨어프로젝트 개발로력승수 {software 
effort multiplier) 들을 곱해야 한다. 이러한 승수들과 그 값들을 그림 9-5 에 보여 주었다. 
매 승수는 6개 까지 의 값을 가진다. 실례 로 제 품복잡성승수에는 개 발자들이 프로젝 트의 
복잡성을 매우 낮은것，약간 낮은것，보통인것，좀 높은것，매우 높은것 혹은 극도로 높 
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은것으로 평가하는데 따라서 그 값들은 각각 0.70，0.85，1.00， 1.15, 1.30, 1.65 로 할당하 
고 있 다. 그림 9-5 에서 볼수 있는것 처 럼 15개 의 모든 승수들은 해 당한 파라메터 가 보통 
일 때 값 1.00 을 가진다. 





등 

급 




아주 




아주 

극도로 

비용결정요인 

낮다 

낮다 

보통 

높다 

높다 

높다 

제품특성 







요구 하는 
쏘프트웨어믿음성 

0.75 

0.88 

1.00 

1.15 

1.40 


자료기 지 크기 


0.94 

1.00 

1.08 

1.16 


제품의 복잡성 
를퓨터 특성 

0.70 


1.00 

1.15 

1.30 

1.65 

실 행 시 간제 한 



1.00 

1.11 

1.30 

1.66 

기 본보관제 한 



1.00 

1.06 

1.21 

1.56 

가상기계 휘발성* 


0.87 

1.00 

1.15 

1.30 


를퓨터 순회 시간 
성원 특성 


0.87 

1.00 

1.07 

1.15 


분석 자능력 

1.46 

1.19 

1.00 

0.86 

0.71 


응용경험 

1.29 

1.13 

1.00 

0.91 

0.82 


프로그람작성자능력 

1.42 

1.17 

1.00 

0.86 

0.70 


가상기 계 경험* 

1.21 

1.10 

1.00 

0.90 



프로그람작성언어경험 

1.14 

1.07 

1.00 

0.95 



쓰도여 드一생 

현대프로그람작성실천 
에서의 리용 

1.24 

1.10 

1.00 

0.91 

0.82 


쏘프트웨 어 도구 

1.24 

1.10 

1.00 

0.91 

0.83 


요구되는 개발일정계획 

1.23 

1.08 

1.00 

1.04 

1.10 



주어 진 쏘프트웨어 제 품에 대 하여 기 초적 인 가상기 계 는 과제 를 수행 하기 위 하여 
요구하는 하드웨 어 와 쏘프트웨 어(조작체 계 , 자료기 지 관리 체 계)의 복합체 이다. 


그림 9-5. 중간 COCOMO 쏘프트웨 어 개 발로력승수 
[ Boehm , 1984 b ]. [©1984 正 EE .] 


보엠 은 파라메터 가 실제 적 으로 비률이 명 목상인가 혹은 그보다 더 낮은가 혹은 더 
높은가 하는것을 개발자가 확증하는데 도움을 줄수 있는 지도서를 내놓았다. 실례로 모 
둘복잡성승수를 다시 생각해 보자. 만일 모둘의 조종연산들이 본질상 ( if - then - else , do - 
while , case 와 같은) 구조화프로그람작성의 구성들의 순차적인 렬로 이루어 져 있다면 
복잡성은 대 단히 낮은것 으로 평 가된다. 만일 이 연산자들이 함유되 여 있으면 비률은 낮 
다. 내부모둘의 조종과 결정표들을 추가하는것은 명목상의 평 가를 증가시키는것으로 된 
다. 만일 연산자들이 복합술어 들로 고도로 함유되 여 있고 대 기렬들과 탄창들이 있다면 
평가는 높게 설정된다. 재입력가능하고 재귀적인 코드작성과 고정된 우선권중단처리가 
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있으면 평가를 대단히 높은것으로 되게 한다. 끝으로 동적으로 변화하는 우선권들과 마 
이크로코드준위 조종을 가지는 다중자원처 리계획 작성은 평 가를 극도로 높은것 으로 설정 
한다. 이러한 비률은 조종연산들에도 적용된다. 모둘은 또한 계산처리와 장치의존적인 
처리，자료관리연산의 견지에서도 평가되여야 한다. 매 15개의 승수를 계산하기 위한 
기 준에 대 하여 자세한 내 용을 알려 면 문헌 [ Boehm , 1981] 을 참고하시 오. 

이것을 어떻게 하는가를 보기 위하여 문헌 [ Boehm , 1984 b ] 에서는 고도로 믿음성 이 
있고 새 로운 전자식 자금전송망을 위한 극소형처 리소자에 기 초한 자료통신처 리쏘프트웨 어 
의 실례를 성능과 개발일정계획，대면부요구사항을 포함하여 제시하고 있다. 이 제품은 
내장방식의 서술에 적합하며 크기는 1만개의 원천명령문 (10 KDSI ) 으로써 평가되였다. 그 
리하여 명 목상개 발로력 은 


명목상 로력 = 2.8 x ( KDSI ) 120 (9.7) 

으로 계산된다(여기서 상수 2.8 과 2.0 은 내장된 제품에 대한 자료에 가장 적합한 값들이 
다.). 프로젝트가 크기상 10 KDSI 로 평가되기때문에 명목상 토력은 

2.8 x ( lO ) 1 ' 20 = 44월 공수 

으로 평가된다. 평가된 개발로력은 명목상 토력을 15개의 승수들을 곱하여 엄어 진다. 
이 승수들과 그 비률값들을 그림 9-6 에 주었 다. 이 값들을 리용할 때 승수값은 1.35 이 며 
따라서 이 프로젝 트를 위하여 평 가된 토력 은 

1.35 x 44 = 59월공수 


로 된다. 

이때 이 수는 딸라비용，개 발일정계 획，단계와 활동의 분포，를퓨터비용，년간유지 
정비비용，기타 다른 년간항목들을 확정하기 위한 추가적인 공식으로 리용된다. 자세한 
것은 문헌 [ Boehm , 1981] 에 있다. 중간 COCOMO 는 완전한 알고리듬적 인 비용타산모형 
으로서 사용자들에게 프로젝트 계획작성 에서 실제적으로 있을수 있는 방조들을 모두 제공 
하여 준다. 

중간 COCOMO 는 방대하고 다양한 응용분야들을 포함하는 63개의 프로젝트들에 대 
한 일반적인 실례들과 관련하여 타당하게 되였다. 중간 COCOMO 를 이러한 실례들에 적 
용한 결과 실제값이 대 략 시 간의 68%이 라고 하는 예 측값의 20%이 내 에 있 다는것 이 다. 
중간 COCOMO 를 위한 입 력 자료가 불과_20%정 도내 까지 정 확하기때 문에 대 부분의 기 
업체들에서 이 정확도를 높이기 위한 시도는 거의나 없었다. 그럼에도 불구하고 경험 있 
는 평 가자들에 의하여 얻 어 진 정 확성 은 중간 COCOMO 를 1980년대 기간에 진행한 비 용 
타산연구의 뚜렷한 효과로 인정하게 하였다. 즉 그 어떤 다른 기법도 일관하게 정확성을 
보장하지 못하였다. 

중간 COCOMO 에서 중요한 문제는 그것에 대한 가장 중요한 입력이 목적하는 제품 
에 있는 코드의 행 수이 라는것 이 다. 만일 이 러 한 평 가가 정 확하지 않으면 그때 에 는 모형 
에 대 한 모든 단순한 예 측이 부정 확하게 될 수 있다. 중간 COCOMO 예 측 또는 그 어 떤 
다른 평가방법이 부정확할수도 있다는 가능성 이 있는것으로 하여 관리자측은 쏘프트웨어 
개 발전반에 걸쳐 모든 예 측들을 감시 하여 야 한다. 
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비용결정요인 

상 황 

등급 

로력 승수 

요구되는 
쏘프트웨 어 믿 음성 

쏘프트웨어고장의 엄중한 재정 
적인 후과 

높다 

1.15 

자료기 지 크기 

20,000바이트 

낮다 

0.94 

제품의 복잡성 

통신처리 

아주 

높다 

1.30 

실행 시간제한 

리용가능한 시 간의 70%리용 

높다 

1.11 

기 본보관제 한 

64 K 보관능력중에서 45 K 
:보관(70%) 

높다 

1.06 

가상기 계 휘 발성 

상업적인 마이크로처리기 
하드웨어에 기초 

모통 

1.00 

를퓨터순회시간 

두 시 간 평 균순회 시 간 

보통 

1.00 

분석 자능력 

고급한 분석 자작성 자 

높다 

0.86 

응용경험 

3 년 

보통 

1.00 

프로그람작성자능력 

고급한 프로그람작성자 

높다 

0.86 

가상기 계 경험 

6개월 

낮다 

1.10 

프로그람작성언어경험 

12개월 

1 통 

1.00 

현대프로그람작성실천의 
리 용 

년간리용에서 최고기술 

높다 

0.91 

쏘프트웨 어 도구 

기 초적 인 소형콤퓨터 도구준위 

낮다 

1.10 

요구과는:개발일정계획 

9개월 

보통 

1.00 


그림 9-6. 극소형 처 리 기통신쏘프트웨어를 위 한 중간 COCOMO 
쏘프트웨 어 개 발로력 승수 [ Boehm , 1984 b ]. [©1984 IEEE .] 


9. 2. 4. COCOMO II 

COCOMO 는 1981 년에 제 안되 였 다. 그때 사용하고 있 던 유일한 생 명 주기모형 은 폭포 
모형이 였다. 의뢰 자-봉사기 와 객체지향과 같은 기 법 들욘 본질에 있어서 알려 져 있지 않 
았다. 따라서 COCOMO 는 이러한 요인들가운데서 그 어느 요인도 병합하지 않고 있다. 
그러 나 보다 더 새 로운 기 술들이 공인된 쏘프트웨 어공학실 천 으로 등장하기 시 작하자 
COCOMO 는 그 정 확성 이 낮아 지기 시 작하였다. 

COCOMO II [Boehm et al., 200 이은 1981 년의 COCOMO 를 개정 한 주요판본이 다. 
COCOMO II 은 객체지향과 3 장에서 설명한 여 러 가지 생 명 주기 의 모형들, 신속원형작성 
(10.3), 4 세 대 의 언 어 들 (14.2), 재 리용 (8.1), COTS 쏘프트웨 어 (2.1) 를 비 롯하여 아주 다양한 
현대 쏘프트웨 어 공학수법 들을 처 리할수 있 다. COCOMO II 는 유연하고 정 교하다. 유감스 
럽게도 이 목적을 달성하기 위하여 COCOMO II 는 또한 원래의 COCOMO 보다 매우 복 
잡하다. 따라서 COCOMO II 를 리용하려 고 하는 독자들은 문헌 [Boehm et al., 2000] 을 
자세 히 연구하여 야 한다. 즉 여기서는 다만 COCOMO II 와 중간 COCOMO 사이의 중요 
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한 차이들에 대하여 개괄하고 있다. 

우선 중간 COCOMO 는 코드의 행 ( KDSI ) 에 기초한 한개의 총체적 인 모형 으로 이루어 
져 있다. 한편 COCOMO II 는 세개의 각이한 모형들로 이루어 져 있다. 객체점(기능점 
과 류사하다.)에 기 초한 응용프로그람합성 모형 ( a / 少 // composition model ) 은 개 발되 는 
제품과 관련하여 최소한의 지식이 리용되던 초시기의 단계들에서 적용된다. 그다음 더 
많은 지식이 리 용되게 되자 초기 설계 모형 ( ear/_y design model ) 이 리용된 다. 즉 이 모형은 
기능점들에 기초하고 있다. 마지막에는 개발자들이 최대의 정보를 가지게 되자 우편구성 
방식 모형 ( pcMtorc / n ’/ ec/Mre model ) 이 리 용된 다. 이 모형 은 기 능점 들 혹은 코드행 ( KDSI ) 
들을 리용한다. 중간 COCOMO 로부터 나오는 출력 은 비 용과 크기 의 타산이 다. 

즉 COCOMO II 의 세개 모형가운데 서 매 모형 에 서 나오는 출력 은 비 용과 크기타산 
의 범위로 된다. 따라서 만일 토력에 대한 타산을 표라고 하면 응용프로그람합성모형은 
범위 (0.80 E , 1.25 E ) 를 귀환한다. 이것은 COCOMO II 의 모형들의 발전과정 에 정 확도가 
높아 지 는 과정 을 반영하여 주고 있 다. 

두번째 차이 는 COCOMO 에 기 초한 로력모형 에 있 다. 즉 

토력 : a x (크기) 6 (9.8) 

이 다. 여 기서 a 와 b 는 상수이다. 중간 COCOMO 에서는 지수 6에 대 하여 세개의 서 로 다 
른 값들을 주고 있는데 그 값들은 개 발되는 제품의 방식 이 단순한 방식 (6=1.05) 인지 중 
간방식必 =1.12) 인지 혹은 복잡한 방식 (6=1.20) 인가에 달려 있다. COCOMO II 에서 6의 
값은 1.01 과 1.26 사이에서 변하며 이것은 모형의 다양한 파라메터에 의존하고 있다. 이 
것들은 그러한 류형의 제품들과의 친숙성，처리성숙준위 (2. 11)，위험해소의 크기 (3. 6절) 
그리고 림의 협동정도 (4.1) 를 포함하고 있다. 

세번째 차이 는 재 리용과 관련한 추측이 다. 중간 COCOMO 는 재 리용으로 인한 절 약이 
재리용량에 직접적으로 비례하고 있다고 가정하고 있다. COCOMO II 는 재리용된 쏘프 
트웨어 에서 발생한 자그마한 변화들이 불균형적으로 큰 변화들을 초래 하고 있다고 생각 
하고 있다(왜 냐하면 코드가 거의 자그마한 변화에 대 하여서는 구체 적 으로 리해되며 수정 
된 모둘들을 시 험하는 비 용이 상대 적 으로 크기 때 문이 다). 

넷째 로 중간 COCOMO 안에 는 15개 대신 17개 의 비 용타산요인승수들이 있다. 비 용타 
산요인중 7개 는 앞으로의 제 품들에 서 요구될 재 리용성 과 매 해 직 원들의 재 편성 그리 고 
제 품이 여 러 곳에 서 개 발되 고 있는가 하는것 과 같은 새 로운것 들이 다. COCOMO II 는 다 
양한 서 로 다른 령역 들에 서 취 한 83개 의 프로젝 트들을 리용하여 조사하였 다. 모형 은 여 
전히 너무 새로운것이여서 그것의 정확도와 특히 그것의 이전의 모형 즉 원래 (1981 년)의 
COCOMO 에 비하여 개선된 정도와 관련하여 많은 결과들이 나왔다. 

9. 2. 5. 기간과 비용타산의 추적 

제품이 개발되고 있는동안 실제적인 개발노력은 예측들과 끊임없이 비교되여야 한다. 
실 례 로 쏘 프트웨 어 개 발자들이 리 용한 타산량이 명세 작성 단계 가 3개 월 걸 리 고 7명 이 1 개 
월동안 하는 노력을 요구한다고 가정하자. 그러나 4개월이 지 나 가고 W 명 이 1개월동안 
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하는 노력이 지출되였다. 그러나 아직 명세서는 결코 완전하지 못하다. 이러한 편향은 
무엇인가 잘못된것이며 따라서 수정해야 한다는것을 초기에 경고할수 있다. 문제는 제품 
의 크기 가 과소평 가되 였고 개 발림 이 생각했던것만큼 충분한 능력 이 없다는데 있을수 있 
다. 리유가 무엇이든간에 기간이 오래 지속되고 비용이 초과되였으므로 관리자는 그 영 
향을 최소화하기 위하여 적절한 조치를 취해야 한다. 

예 측에 대 한 세 밀 한 추적 은 예 측을 진행 한 기 법 들에 관계 없 이 개 발전과정 에 걸 쳐 진 
행되여야 한다. 편향은 서투른 사용자와 불충분한 쏘프트웨어개발 그리고 량자의 결합 
과 기타 다른 리유로 되는 척도에 기인될수 있다. 중요한것은 편향들을 신속하게 찾아 
내고 즉시에 수정대책을 세우는것이다. 

9.3. 쏘프트웨어 프로젝트관리계획의 구성요소 

쏘프트웨 어프로젝트관리계획에는 세개의 기본구성 요소들이 있다. 즉 하여 야 할 일， 
그것을 하는데 필요한 자원들, 그 모든것에 지불해야 할 비용이 있다. 이 절에서는 이 
세 구성 요소들에 대 하여 론의한다. 용어 는 문헌 [IEEE 1058.1，198刀에서 찾아 볼수 있 
는데 그것 은 9.4 에 서 더 자세 히 론의하기 로 한다. 

쏘프트웨 어개 발은 자원 ( mwwrce ) 을 요구한다. 필요한 주요자원들로는 쏘프트웨어 를 
개 발하는 사람들과 쏘프트웨어를 실행시 킬 하드웨 어，조작체계，본문편집프로그람，판본 
조종쏘프트웨 어 (5.7) 와 같은 지 원쏘프트웨어 들이다. 

개발성원들과 같은 자원비용은 시기에 따라 달라 진다. 노덴 ( Norden ) 은 큰 프로젝트 
에 대 하여 레 일리 ( Rayleigh ) 분포가 자원소비 兄는 시 간 /에 따라 변화한다는것 을 가장 가 
깝게 반영하고 있다는것을 문헌 [ Norden , 1958] 에서 보여 주었다. 즉 

Rc = ^2 e t，2k 0 ~ t<o ° (9.9) 

파라메터 소는 소모가 정점에 이른 시간 즉 상수이며 ^2.71828 •••는 나쁠레옹로그의 밑수 
이 다. 전형적 인 레이레그곡선을 그림 9-7 에 보여 준다. 자원소모는 작게 시 작하여 급격 
히 정점으로 뛰여 오르며 그다음에는 보다 낮은 속도로 줄어 든다. 푸트남 ( Putnam ) 은 쏘 
프트웨어개 발에 대 한 노덴의 결과들의 적 용가능성 을 조사하고 개 발성 원들과 다른 자원소 
모가 레이레그분포에 따라 일정한 정도로 정확성을 가지고 모형화되였다는것을 발견하였 
다 [ Putnam , 1978]. 

따라서 단순히 적어도 5년간의 경험을 가진 세명의 고급프로그람전문가들이 요구된 
다고 말하는것은 쏘프트웨어계획에서는 불충분하다. 다음과 갈은 것들이 필요하다. 

실시간 프로그람작성에서 최소한 5년간의 경험을 가진 3명의 고급프로그람전문가들이 필요 
하다. 2명 은 프로젝 트개 발이 시 작된 다음 3개 월 만에 개 발에 착수하고 세번째 사람은 그다음 
6개 월 후에 개 발에 착수한다. 2명 은 제 품시 험 이 시 작될 때 단계 적 으로 물러 나며 세번째 사 
람은 유지정비 가 시 작될 때 점 차적으로 물러 난다. 
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그림 9-7. 자원소비 가 시 간에 따라 변한다고 하는 레이 레 그곡선 

자원수요가 시 간에 의 존한다는 사실은 개 발성원들에 게뿐아니 라 콤퓨터시 간，지 원쏘 
프트웨어，를퓨터하드웨 어，사무소설비능력에도 적용된다. 그리하여 쏘프트웨 어프로젝 트 
관리계획은 시간의 함수로 될것이다. 

해 야 할 과제 는 두가지 부류로 갈라 볼수 있다. 첫째 로，프로젝트 전 기 간에 걸쳐 계 
속되 며 쏘프트웨 어개 발의 그 어 떤 특정한 단계 와 관계 되 지 않는 일 이 다. 그러한 작업 을 
프로젝트기능어 rayec // wncft ’ o «) 이라고 부론다. 실례로 프로젝트관리와 품질조종을 들수 있 
다. 두번째 로，제 품개 발에 서 특정한 단계 와 관련되 는 작업 이 다. 즉 그러한 작업 을 활동 
( activity ) 또는 과제 ( to 伏)라고 부론다. 활동은 정확한 시작과 끝나는 날자들이 있는 작업 
의 기 본단위 이 다. 즉 콤퓨터 시 간 또는 일 공수와 같은 자원들을 소비 하고 예 산，설 계문서 , 
일정계획，원천코드 또는 사용자지도서와 같은 작업제품 ( HWVt / WK/M 功들로 된다. 결과 활동 
에는 과제 즉 관리책임에 따르는 작업의 가장 작은 단위인 과제의 모임이 포함된다. 쏘프 
트웨어프로젝트관리계획에는 세가지 종류의 작업들이 있다. 즉 프로젝트전기간에 걸쳐 수 
행되는 프로젝트기능，활동(작업의 주요단위)，과제(작업의 부차적인 단위)들이 있다. 

제품의 결정적인 측면은 작업제품들의 완성과 관련된다. 작업제품이 완성된다고 생 
각하는 날을 리정표이라고 부론다. 작업제품이 실제로 리정표에 이르렀는가 하 
는것 을 결 정 하기 위 하여 서 는 그것 에 대 하여 우선 림 의 동료들과 관리 자 또는 의 뢰 자에 
의하여 수행 되 는 검 토를 련속 진행하는것 이 다. 전형 적 인 리 정 표는 설계 가 완성 되 고 검 토 
에 통과되는 날이다. 일단 작업제품이 검토된후에 합의되면 그것은 기준선(노으로 
되며 5.8.2 에서 설명한것처럼 공식적인 처리절차를 통하여 변경될수 있다. 

사실상 단순히 제품 그자체보다도 작업제품에 더 많은것이 있다. 작업패키지는 바로 
작업제품들뿐아니라 성원요구，지속，자원，개별적인 책임의 이름，작업제품을 위한 승 
인기 준을 정의한다. 물론 비 용은 계 획 에서 사활적 인 구성요소이 다. 구체 화된 예 산이 작 
성되여야 하며 시간의 함수로서 프로젝트기능들과 활동에 비용이 활당되여야 한다. 

쏘프트웨 어제 품개 발을 위한 계 획 작성 과 관련 한 문제 는 다음절 에 서 서 술한다. 
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9.4. 쏘프트웨어 프로젝트관리계획의 틀거리 

그림 9-8 은 IEEE 규격 1058.1 [IEEE 1058.1, 198刀에 규정 된 쏘프트웨 어 관리 계 획 ( SPMP ) 
의 부분제 목들을 보여 주고 있다. 비 록 SPMP 를 작성하는 다른 많은 방법 들이 있 다고 하 
여 도 IEEE 규격 에 따르는데 는 명 백 한 우점 이 있 다. 


1 소개 

1.1 

프로젝트 개괄 

1.2 

프로젝트 배포 

1.3 

쏘프트웨어프로젝트관리계획의 발전 

1.4 

참고자료 

1.5 

정의와 줄임말 

2 프로젝트의 구성 

2.1 

공정 모형 

2.2 

기업체의 구성 

2.3 

기업체의 경계와 호상결합 

2.4 

프로젝 트책 임성 

3 관리공정 

3.1 

관리목적과 우선도 

3.2 

가정，의존성, 제한 

3.3 

위험관리 

3.4 

감시 및 조종 기구 

3.5 

성원모집계획 

4 기 술공정 

4.1 

방법, 도구, 기술 

4.2 

쏘프트웨 어 문서 작성 

4.3 

프로젝트지원기#_ 

I 5 작업패키지, 일정계획, 예산 I 

5.1 

작업패키지 

5.2 

의존성 

5.3 

자원요구 

5.4 

예산과 자원할당 

5.5 

일정계획 

보충적인 구성요소 


그림 9-8. IEEE 쏘프트웨 어 프로젝 트관리 계 획의 구성 요소 
[IEEE 1058.1, 1987]. [©1987 IEEE.] 

첫 째 로, 그것 이 쏘프트웨 어개 발에 참가하는 주요기 업체 들의 대 표자들에 의해 작성 된 
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표준이 라는것 이 다. 공업과 대 학들에서 자금을 투자하고 실무그롭과 심 사림성 원들은 프로 
젝트관리계획작성에서 다년간의 경험을 가지고 있다. 표준은 이 경험을 통합한다. 두번 
째 우월성은 IEEE SPMP 가 크기에 관계없이 모든 형태의 쏘프트웨어제품들을 리용하는 
데 적 합하도록 설계 된다는것 이 다. 그것은 특정한 개 발공정모형 을 강요하거 나 특정한 방 
법 을 규정하지 않는다. 본질상 계 획은 특정한 응용분야를 위한 매 개 기 업체，개발림 , 기 
법들에 의하여 적 당하게 고쳐 진 내용들인 틀거 리 이 다. 산업적 인 토대에 기초한 이 러한 
틀거 리 를 견지 함으로써 표준화의 우월성 이 나타나게 된 다. 결 국 모든 쏘프트웨 어개 발성 
원들이 IEEE 쏘프트웨 어프로젝 트 관리 계 획 형 식 에 익 숙되 게 될 것 이 며 회 사들은 새 로운 
개 발성 원들을 양성 하는 비 용을 절 약하게 될 것 이 다. 

9. 5. IEEE 쏘프트웨어 프로젝트관리계획 

이제 계획틀거리자체를 자세히 설명하기로 한다. 본문에 있는 번호들과 표제들은 그 
림 9-8 에 있는 서 술항목들에 대 응한다. 여 기서 리용한 여 러 가지 용어 들은 9.3 에서 정 의 
되였다. 

1. 소개 SPMP 에 대 한 다섯개의 소절들은 프로젝트와 개 발될 제 품들에 대 한 총체 적 
인 견해를 주게 된다. 

1.1. 프로젝트개팔 여기서는 프로젝트 목적，배포하게 될 제품들，활동 그리고 결과적인 
작업제품들에 대한 간단한 설명을 준다. 이밖에 필요한 자원들과 기본일정계획 그리고 
기본예산과 갈은 리정표들이 목록으로 작성되게 된다. 

1.2. 프로젝트의 배포 의뢰 자들에게 배포될 모든 항목들은 배포날자들과 함께 이 단계 
에서 목록작성되게 된다. 

1.3. 쏘프트웨어프로젝트관리계획의 발전 그 어떤 계획도 구체적으로 만들어 질수 없다. 
임의의 다른 계획들과 마찬가지로 SPMP 도 경험과 의뢰자측，쏘프트웨어개발기업체내에 
서의 변화에 따라 계속 갱 신되 여 야 한다. 이 절에서는 계 획을 변화시키기 위한 형식적 인 
절차들과 기구들에 대 하여 서술하였다. 

1.4. 참고자료 SPMP 에서 참고하는 모든 문서들이 참고자료안에 목록작성된다. 

1.5. 정의들과 략어 이 정 보는 SPMP 가 모든 사람들에게 똑같이 리해되도록 하게 한다. 

2. 프로젝트의 구성 프로젝트개발기업체에 대한 부분은 4개로 되여 있는데 여기서는 
쏘프트웨 어개 발공정과 개 발자들의 기 업체구조의 견지 로부터 제품이 어떻게 개 발되는가 
하는데 대하여 자세히 서술하고 있 다. 

2.1. 공정모형 공정모형 은 제 품설 계 혹은 제 품시 험 과 갈은 활동들과 프로젝 트관리 혹 
은 구성관리와 같은 프로젝트기능과 관련하여 자세히 서술된다. 여기서 기본적인 측면들 
은 리정표들，기준선들, 검토，작업제품，배포에 관한 설명들이 포함된다. 

2.2. 기업체의 구성 여 기서 는 개 발기 업 체의 관리구조가 서 술된다. 기 업체내의 권한과 
책임한계를 명백히 하는것이 중요하다. 

2.3. 기업체의 경계와 호상결합 진공속에서는 그 어떤 프로젝트도 개 발되지 못한다. 프 
로젝 트개 발성 원들은 의뢰 자측과 자기기 업체의 다른 성 원들과 호상작용하여 야 한다. 더우 
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기 그 중간에 있는 청부업 자들이 큰 프로젝트개발에 참가할수 있다. 프로젝트 그자체와 
이러한 다른 구성요소들사이의 관리 및 경영상의 한계가 그어 져 있어야 한다. 그밖에 
많은 쏘프트웨 어개 발기 업체들은 두가지 류형의 그룹들 즉 단일한 프로젝트개 발에 참가하 
는 그룹들과 기업체구성의 토대우에서 구성관리 및 쏘프트웨어품질보증과 같은 지원기능 
을 제공하는 지원그를들로 갈라 진다. 프로젝트개발그룹과 지원그롭사이의 행정관리 및 
경영상의 한계가 명백히 규정되여 있어야 한다. 

2.4. 프로젝트책임성 SQA 와 같은 매개 프로젝트 기능과 제품시험과 갈은 매개 활동을 
책임질 개별적사람들을 확인하여야 한다. 

3. 관리공정 이 부분에는 프로젝트가 어떻게 관리되는가 하는데 대하여 다섯가지로 
설 명 한다. 

3.1. 관리목적과 우선권 관리를 위한 원리，목표 그리고 우선권들을 서술한다. 계획에 
대한 항목들의 형태들은 보고서 작성의 빈도수와 기구，요구중에서 상대적 인 우선권，프 
로젝 트를 위한 일정 계 획과 예산 그리 고 위험 관리절차들시 포함된다. 

3.2. 가정, 의존성, 제약조건 명세서에 있는 가정들과 제약조건들이 여기에 포함된다. 

3.3. 위험관리 프로젝 트와 관련한 여 러 가지 위 험 인자들이 이 것 들을 추적하는데 리용되 
는 방법들과 함께 여기서 목록작성된다. 

3.4. 감시 및 조종기술 검토 및 회계를 비롯하여 프로젝트를 위한 보고서작성기법들이 
자세히 서술되여 있다. 

3.5. 성원계획 프로젝트개발에 참가하는 성원들은 중요한 자원을 이룬다. 필요한 성원 
들의 수와 류형들을 그들이 필요한 기 간과 함께 렬거하여 야 한다. 

4. 기술공정 프로젝트의 기술적인 측면이 아래의 세가지로 설명된다. 

4.1. 방법 도구, 기법，하드웨어와 쏘 프트웨 어의 기술적인 측면들이 여기에서 자세히 
설명된다. 여기에는 제품이 실행될 목적체계들뿐아니라 제품을 개발하는데 리용될 콤퓨 
터체계들(하드웨 어 , 조작체 계，쏘 프트웨 어)이 포함된다. 필요한 다른 측면들로서는 리용 
될 개 발기 법，시 험 방법，림 의 구조，프로그람작성언어 그리 고 CASE 도구들을 들수 있 다. 
그밖에 문서 작성표준들과 코드작성표준들과 갈은 기 술표준들이 작업제 품들을 개 발하고 
수정 하기 위한 절 차와 다른 문서 들을 참고하여 포함되 게 된 다. 

4.2. 쏘프트웨어문서작성 여기에는 문서작성요구들 즉 리정표들과 기준선들 그리고 쏘 
프트웨 어 문서 작성 을 위 한 검 토들 이 서 술된 다. 

4.3. 프로젝트지원기능 여기서는 시험계획을 비롯하여 구성배치관리와 품질보증과 갈은 
지 원기 능을 위한 계 획 들을 구체 화한다. 

5. 작업패키지, 일정계획, 예산 아래에서 작업패키지，그것들사이의 호상의존성，자원 
요구 그리고 련관된 예산할당들에 대하여 강조한다. 

5.1. 작업패키지 여기서는 작업패키지들을 활동들과 과제들로 분할된 련관된 작업제품 
들과 함께 자세히 서술한다. 

5.2. 의존성 모든 코드작성은 설계 다음에 진행되며 통합 및 시험 에 앞서서 진행한다. 
일 반적 으로 작업패 키지 들에서의 호상의존성 과 외 부사건들에 대 한 의존성 이 존재한다. 여 
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기서 이 의존관계들을 서술한다. 

5.3. 자원요구 프로젝트를 완성하기 위하여서는 광범하고 다양한 자원들이 요구된다. 
전체 자원들은 시간의 함수로 제공된다. 

5.4. 예산과 자원할당 여기서 렬거된 여러가지 자원들은 비용이 든다. 바로 자원이 시 
간이 지나감에 따라 변화되는것처럼 여러가지 구성요소자원들에 대한 예산할당도 변화된 
다. 여러가지 프로젝트기능들，활동들，그리고 과제들에 대한 자원들과 예산들의 할당이 
진행된다. 

5.5. 일정계획 프로젝트의 매개 구성요소들을 위한 구체화된 일정계획 이 주어 진다. 
이러한 기본계획이 뒤따르게 된다. 즉 프로젝트가 제때에 그리고 예산범위내에서 완성될 
것을 요구한다. 

추가적인 구성요소 일정한 프로젝트들을 위한 추가적인 구성요소들이 계획에 반 
영되여야 한다. IEEE 틀거리에 비추어 그것들은 계획의 마감에 있게 된다. 추가적인 
구성요소들에는 청부업자관리계획，안전계획，시험계획，양성계획，하드웨 어조달계 
획，설치계획 그리고 제품유지정비계획들이 포함된다. 

9. 6. 시험계획작성 

SPMP 에서 자주 무시하게 되는 구성요소는 시험계획작성이다. 쏘프트웨어개발의 다 
른 모든 활동과 마찬가지 로 시험 이 계 획되 여 야 한다. SPMP 에는 시험을 위한 자원이 포 
함되여야 하며 구체화된 일정계획에서는 매 단계에서 수행하여야 할 시험이 명백히 지적 
되여야 한다. 

시험계획이 없이는 프로젝트개발이 많은 면에서 잘못 진행될수 있다. 실례로 제품 
시 험 (2.6.1) 기 간에 SQA 그룹은 명세서의 모든 측면들이 의뢰 자에 의해서 계 약명기되는 
것처 럼 완성된 제품에서 실현되였는가를 시험하여 야 한다. 이 과제수행 에서 SQA 그룹 
을 지원하는 좋은 방안은 개발이 추적가능하도록 요구하는것이다. 즉 명세서에 있는 
매 개 설명 문을 설계 의 부분들에 련결시키 는것 이 가능해 야 하며 그리 고 실례 의 매 개 부 
분을 코드에 명백 히 반영하여 야 한다. 이것을 달성 하기 위한 한가지 기술은 명세서 에 
있는 매개 설명문들에 번호를 달아 주고 이 번호들이 설계와 결과코드에 반영되도록 
하는것 이 다. 그러 나 만일 시험계획 이 이것을 진행하게 된다는것을 자세 히 서술해 두지 
않는다면 설계 와 코드에 적 당히 표시 기호를 달아 놓을것 까지 는 필요 없 다. 결과제 품시 
험이 최종적으로 수행될 때에 SQA 그를이 제품이 명세서에 맞게 완전히 실현되였다는 
것 을 확정하는것 은 대 단히 어 려울것 이 다. 사실 상 추적가능성 은 요구사항확정단계 와 함 
께 시 작되 여 야 한다. 즉 요구사항확정문서 에 있는 매 개 설명 문(혹은 신속원형 의 매 부 
분)은 설계의 부분들에 련결되여야 한다. 

검열의 한가지 위력한 측면은 검열기간에 발견된 오유들에 대한 구체적인 목록에 있 
다. 어느 한림이 제품의 명세서를 검열하고 있다고 하자. 6.2.3 에서 설명한것처럼 오유 
들에 대한 목록은 두가지 방식으로 리용된다. 첫째로，이 검열로부터 뽑아 낸 오유통계 
는 이전의 명세서검열에서 나온 축적된 평균고장통계와 비교하여야 한다. 이전의 기준으 


294 



로부터 벗어 난것들은 프로젝트 안에서 문제가 있다는것을 의미한다. 둘째로，현재 진행 
중의 명세서검열에서 나온 오유통계는 제품의 설계 및 코드검열들에 넘겨 져야 한다. 결 
국 만일 특정한 형태의 수많은 오유들이 있으면 명세서검열기간에 모두 검출되지 못할수 
있으며 설계 및 코드검열들에서는 이 형태의 그 어떤 나머지오유들을 보충적으로 찾아 
낼수 있게 해준다. 그러나 만일 시험계획이 모든 오유들의 세부적인것들을 자세히 기록 
되여야 한다는것을 강조하지 않으면 이러한 과제는 수행될것 갈지 않다. 

코드모둘을 시험하는 한가지 중요한 방도는 코드가 명세서에 기초한 시험실례들로 
시험을 진행 하는 검은통시 험 (14.7) 이다. SQA 그룹의 성원들욘 명세서를 쭉 읽고 코드가 
명세서 에 부합되는가를 검 열하기 위하여 시험실례를 작성한다. 검은통시험실례들을 작성 
하는 가장 좋은 시 간은 명세작성의 마감이다. 그러 나 만일 시 험 계 획 이 검 은통시 험실례 들 
을 이 시간에 선택하게 된다는것을 명백히 강조하지 않으면 아마 십중팔구는 다만 몇개 
의 검 은통시험실례 들만이 그후에 날림식 으로 그러 모아 만들어 지 게 될것 이 다. 즉 SQA 그 
룹이 그것의 모둘들이 전체 로서 제 품에 통합될수 있게 모둘들을 승인하도록 하기 위해 
프로그람개발림 으로부터 요구가 높아 질 때 에만 제 한된 수의 시험실례 들이 신속하게 수 
집된다. 결과 전체로서의 제품의 품질은 진통을 겪게 될것 이다. 

따라서 모든 시험계 획은 무슨 시험을 진행하게 되고 또 그것 이 언제 진행되 여 야 
하며 또 그것이 어떻게 수행되게 되겠는가 하는것을 자세히 서술해 주어야 한다. 그 
러한 시험계획은 SPMP 에 대한 4.3 에서 본질적인 부분으로 되고 있다. 그것이 없이는 
제품의 품질은 틀림없이 진통을 겪게 될것이다. 

9.7. 객체지향프로젝트의 계획작성 

구조화파라다임을 리용한다고 하자. 개념적인 견지에서 볼 때 결과제품이 촉■립적인 
모둘들로 구성되 여 있다고 하더 라도 그것은 일반적으로 하나의 큰 단위 이다. 그와 상반 
되게 객체지향파라다임을 리용하는것은 수많은 상대적으로 독립인 보다 작은 구성요소 
들 즉 추상화의 분석 및 구성 방식설계준위들에 있는 클라스들과 구체화된 설계 및 실현 
준위들에서의 객체들로 이루어 진 제품을 라렬화하는것으로 된다. 이것은 비용 및 기간타 
산들이 보다 더 작은 단위들을 위하여 더 쉽고 더 정확하게 계산될수 있다는 점에서 계획 
작성을 상당히 쉽게 해준다. 물론 제품에 대한 평가가 바로 그것의 부분들에 대 한 평가의 
합보다 더 많다는것을 고려하여야 한다. 개별적인 구성요소들은 완전히 목립이 아니다. 
즉 그것들은 서로 호출할수 있다. 그리고 이러한 영향들은 무시하지 말아야 한다. 

이 장에서 설명한 비용과 기간을 타산하기 위한 기술적인 방법들이 객체지향파라 
다임에 리용될수 있는가? COCCMO II (9.2.4) 은 객체지향을 비롯하여 현대적인 쏘프트 
웨 어기술을 관리 하기 위하여 설계되 였 다. 그러 나 기능점 들 (9.2.1) 과 중간 COCCMO (9.2.3) 
과 같은 초기의 척도는 어떤가? 중간 COCCMO 의 경우에 일부 비용승수들에 대하여 
보다 적 은 변경 을 진행 하여 야 한다 [ Pittman , 1993]. 그밖에 구조화파라다임 의 평 가도구 
들은 재리용되지 않으면 객체지향파라다임들에서 제대로 동작하지 않을것 갈다. 재리 
용은 객체지향파라다임 을 두가지 방식 으로 입 력한다. 개 발기 간에 현존구성 요소들의 재 
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리용과 앞으로의 제품에 재리용하게 될 구성요소들의 계획적인 생산(현재의 프로젝트 
개발기간에)을 입력하게 된다. 재리용의 두 형태들은 평가과정에 영향을 준다. 개발기 
간에 재 리 용은 명 백 히 비 용과 기 간을 줄인 다. 이 재 리 용기 능에 의 한 절 약을 보여 주는 
공식들이 발표되였다 [ Schach , 1994]. 그러나 이 결과들은 구조화파라다임과 관련되여 
있다. 현재 객체지향제품개발에 재리용이 전개될 때 비용과 기간이 어떻게 변하는가 
하는것과 관련해서는 그 어떤 정보도 얻을수 없다. 

이제 현재의 프로젝트의 부분들을 재 리용하는 목적을 고찰하다. 

재 리용가능한 구성 요소를 설 계 하고 실 현 하고 시 험하여 문서 작성하는것 은 류사한 
재 리용불가능한 구성 요소에 비 하여 기 간이 약 3배씩 이 나 오래 걸린 다 [ Pittman , 1993]. 
비 용과 기 간타산은 이 추가적 인 노력 을 통합하기 위하여 수정 되 여 야 하며 전체 로서 의 
SPMP 는 재 리용노력 의 결 과를 통합하기 위하여 조절 되 여 야 한다. 따라서 두 재 리용활 
동들은 반대 방향으로 진행 된다. 현존구성 요소의 재 리용은 객체 지향제 품을 개 발하는데 
서 총체 적 인 노력 을 줄인 다. 반면 에 앞으로의 제 품들에 서 재 리용하기 위한 구성 요소 
들을 설계하는것은 노력을 증대시킨다. 전망적으로 클라스들의 재 리용으로 인한 절약 
이 원래의 개발비용보다 더 많을것으로 예상되며 일부 근거가 이미 확증되였다 [ Lim , 
1994]. 


9.8. 숙련에 대한 요구 

숙련문제가 의뢰자와의 토의에서 제기되였을 때 공통적인 대답은 《우리는 제품이 
완성될 때까지 숙련에 대해 걱정할 필요가 없다. 그다음 우리는 사용자들을 숙련시킬수 
있다.》는것이다. 이것은 사용자들만이 숙련을 필요로 한다는것을 의미하는것으로서 어 
느 정도 유감스러운 대답이다. 사실상 숙련도 역시 쏘프트웨어계획작성 및 타산에서 숙 
련을 하게 되는것으로 하여 개발림성원들에게도 필요할수 있다. 새로운 설계기법 혹은 
시험절차들과 갈은 새로운 쏘프트웨어개발기법들이 리용될 때 새로운 기법을 리용하는 
모든 림성원들을 숙련시켜야 한다. 

객체지 향파라다임도입은 주로 숙련의 귀결 이 다. 워크스테 이션 ( worfota 的’ o «) 혹은 통합 
된 개 발환경 (15.8) 과 같은 하드웨 어 혹은 쏘 프트웨 어도구들의 도입 에서도 숙련이 요구된 
다. 프로그람작성자들에게는 실현언어에서는 물론 제품개발을 위하여 리용하게 될 기계 
장치 의 조작체 계 에 대 한 숙련 이 요구될 수 있 다. 문서 작성숙련은 아주 많은 문서 들에 대 
하여 품질 이 낮다는것 이 증명된것 처 럼 빈번히 무시 된다. 콤퓨터조작공들에게는 틀림 없이 
새 로운 제 품을 다룰수 있는 숙련 이 일 정하게 요구된 다. 즉 그들은 또한 새 로운 하드웨 어 
가 리용되 면 추가적 인 숙련 을 요구할수 있 다. 

필요한 숙련은 여러가지 방식으로 받을수 있다. 가장 쉽고 좋은 숙련방식은 동업자 
들 혹은 고문들에 의해서 기 업내부에서 수행하는 숙련이다. 많은 회 사들은 다양한 숙련 
과정을 제공해 주며 대학들은 자주 야간숙련과정을 제공해 준다. 

World Wide Web 에 기초한 교육과정은 또 하나의 숙련과정으로 된다. 일단 숙련이 
필요하다는것이 확정되면 숙련계획이 작성되고 그 계획은 SPMP 안에 종합되여야 한다. 
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9. 9. 문서작성규격 


쏘프트웨 어제품개발은 광범하고 다양한 문서작성을 동반한다. 죠네스 ( Jones ) 는 크기 
가 약 50 KDSI 되 는 IBM 내 부의 상업 용제 품을 위하여 1,000개 의 명 령 ( KDSI ) 들마다 28페 지 
의 문서 들이 작성되 며 똑 같은 크기 의 상업 용쏘프트웨어 제품을 위해 KDSI 당 약 68폐 지 
가 작성된다는것을 발견하였다. 조작체 계 MS /360 2.3 판은 크기 가 약 166 KDSI 이며 KDSI 
마다 157폐지의 문서가 작성되였다. 문서는 계획작성，조종，재정 및 기술부서를 비롯하 
여 그 형식들이 다양하다 [ Jones , 1986 a ], 이러한 형식의 문서들외에 원천코드자체는 문서 
의 형태이다. 즉 코드내에서의 주석들은 보충적인 문서를 이룬다. 

쏘프트웨 어개 발노력 의 상당한 몫이 문서 작성 에 돌려 진다. 63개 의 개 발프로젝 트들과 
25개 의 유지 정 비프로젝 트들에 대 한 개 관은 코드와 관련된 활동들에 소모된 모든 100 h 에 
비해 볼 때 150 h 은 문서 작성 과 관련된 활동들에 소모되 였 다는것 을 보여 주었 다 [ Boehm , 
1981]. 큰 TRW 제품들에 한해서는 문서작성과 관련된 활동들에 바쳐 진 시간의 몫이 
100 h 의 코드관련시 간에 비 해 200 h 까지 올라 갔다 [Boehm et al ., 1984]. 

모든 형 태의 문서 작성에는 규격 이 필요하게 된다. 실례 로 설계문서 작성에서 의 통일 
성 은 림성 원들사이 의 오해 를 줄이고 SQA 그룹성 원들을 방조해 준다. 비 록 문서 작성규격 
들과 관련하여 새 로운 성 원들이 양성되 여 야 한다고 하더 라도 기 업체 내 에서 프로젝 트와 
프로젝트사이에 현존 성원들을 옮길 때에는 그 어떤 추가적인 숙련이 필요 없게 된다. 
제 품유지정 비 의 견지 에 서 볼 때 통일 적 인 코드작성규격 들은 유지정 비프로그람작성 자들이 
원천코드를 리해하도록 도와 준다. 규격은 이 것들이 그들중 거의나 를퓨터전문가가 아닌 
광범한 개 별적사람들이 읽 고 리 해 해 야 하기때 문에 리용과 편람들을 위 해서 도 더 중요하 
다. IEEE 는 사용자편 람을 위한 규격 (쏘프트웨어 사용자문서 작성 을 위한 IEEE 규격 1063) 을 
발표하였다. 

계 획 작성공정 의 한 부분으로서 쏘프트웨 어개 발기 간에 작성 된 모든 문서 들을 위한 
규격들이 만들어 져야 한다. 이 규격들은 SPMP 에 통합된다. 쏘프트웨어시험문서를 위 
한 IEEE 규격 [ ANSI/IEEE 829, 1991] 과 같은 현존규격 들이 리 용되 는데 서 는 SPMP (참고자 
료)의 1.4 에 규격 이 목록작성되 여 있다. 만일 개 발노력 을 위해 어 떤 규격 이 특별 히 만 
들어 지 면 그것 은 4.1 에 서 보여 주었 다. 문서 작성 은 쏘프트웨 어개 발노력 의 본질 적 인 측 
면이다. 문서작성이 없이는 제품이 유지정비될수 없기때문에 진정한 의미에서 제품은 
곧 문서이다. 문서작성노력을 자세히 계획작성하고 그다음 그 계획이 준수되도록 하는 
것 은 쏘프트웨 어개 발을 성 과적 으로 진행할수 있게 하는 중요한 요인으로 된 다. 

9.10. 계획작성 및 타산들 위한 CASE 도구 

중간 COCOMO 와 COCOMO II 를 자동화하는 수많은 도구들을 리용할수 있 다. 파라 
메 터 값이 수정되는 경우 계산속도를 위 해 중간 COCOMO 의 여러 개의 실현들이 Lotosl -2- 
3 혹은 Excel 과 같은 표처 리프로그람작성언 어 들로 개 발되 였 다. 계 획 그자체 를 개 발하고 
갱 신하기 위 하여서 는 문서처 리프로그람이 필요하다. 
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관리정보도구들도 역시 계 획작성 에 쓸모가 있다. 실례 로 큰 쏘프트웨어기업체 가 150 
명 의 프로그람작성 자들을 가지 고 있 다고 하자. 일정 계 획작성 도구는 계 획 작성자가 어 느 
프로그람작성 자에 게 특정한 과제 를 할당해 주고 어 느것 이 현재 의 프로젝 트를 위해 리용 
될수 있는가를 기록하는것을 도와 줄수 있다. 

보다 일반적인 형식의 관리정보들도 역시 요구들과 수많은 상업적으로 리용할수 
있는 관리 도구들이 계 획 작성 및 타산과정 을 지 원하고 전체 적 으로 개 발공정 을 감시조 
종하도록 하는데 리용할수 있다. 이 러 한것 들가운데 는 MacProject 와 Microsoft Project 
가 있다. 


9.11. 쏘프트웨어 프로젝트관리계획의 시험 

이 장의 앞부분에서 지적한것처 럼 쏘프트웨 어프로젝트관리체계에서의 결함은 개 
발자들에 있어서 심중한 재정적의미를 가질수 있다는것이다. 개발기업체가 프로젝트 
의 비용 혹은 기간을 과대평가하거나 과소평가하지 않는것이 매우 중요하다. 이것으 
로 하여 전체 SPMP 는 의 뢰 자에 게 평 가결과를 주기전에 SQA 그룹에 의해서 시 험 되 여 
야 한다. 계획을 시험하는 가장 좋은 방법은 11. 11에서 설명한 명세서검열과 류사하 
게 계 획검 열을 진행하는것 이 다. 

계 획검열 림은 비용과 기 간에 특별한 주의를 돌리면서 SPMP 를 구체적 으로 검 토하여 
야 한다. 리 용된 척 도에 관계 없 이 위 험성 을 좀더 줄이 기 위해 계 획 작성림성 원들이 자기 
들의 평 가를 확인 하자마자 비 용과 기 간타산들이 SQA 그롭성 원들에 의해 독자적 으로 평 가 
되여야 한다. 


O 야 

-U- 一 I 

이 장의 기 본주제 는 쏘프트웨 어개 발공정 (9.1) 에 서 의 계 획 작성 의 중요성 이 다. 쏘프 
트웨 어프로젝 트관리 계 획의 중요한 구성요소는 기 간과 비 용 (9.2) 을 타산하는것 이 다. 기 
능점 (9.2.1) 들을 비롯해서 제품의 크기를 타산하기 위한 여러개의 척도가 제기되였다. 
다음으로 비 용타산을 위한 여 러 가지 척 도를 설명하였 다. 특히 중간 COCOMO (9.2.3) 와 
COCOMO II (9.2.4) 를 설명한다. 쏘프트웨 어프로젝 트관리 계 획의 세 가지 구성 요소들 즉 
진행할 작업, 그것을 진행하는데 리 용될 자원들 그리 고 그것 에 적 용한 비 용을 9.3 에서 
설 명 하였 다. 

한가지 특별한 SPMP 인 IEEE 규격 을 9.4 에 서 륜곽적 으로 설 명 하고 9.5 에 서 구체 적으 
로 서 술하였다. 그다음 계 획 작성시 험 (9.6) 과 관련한 절들이 있고 계속하여 객체지향프로 
직 트에 대 하여 서 는 계 획 작성 (9.7) 과 요구사항확정 의 숙련 과 문서 작성규격 들, 계 획 작성공 
정 (9.8 과 9.9) 을 위한 절 들을 취 급하였 다. 9.10 에 는 계 획 작성 및 타산을 위한 CASE 도구 
들이 서술되여 있다. 이 장은 끝으로 쏘프트웨어프로젝트관리 (9.11) 에 대한 시험과 관련 
한 자료들을 서술하였다. 
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보 충 


웨 인비그 (Weinberg) 의 4 권으로 된 저 서 [Weinberg, 1992, 1993, 1994, 199 刀는 [Whitten, 
1995, and Thayer, 199 刀과 같이 쏘프트웨 어 관리 의 많은 측면들에 대 하여 상세 한 정 보를 
제 공해 주고 있 다. 쏘프트웨 어관리 에 대 한 새 로운 견해 들은 문헌 [Reifer, 2000] 에 있 다. 
쏘프트웨 어프로젝 트를 위한 척 도는 문헌 [Weller, 1994] 에 서 론의 되 였 다. 

객체지향파라다임의 관리를 위 하여서는 문헌 [Pittman, 1993, and Nesi, 1998] 을 참고 
할수 있다. 개발자의 생산성에 대한 객체지 향틀거리 [8.5.2] 의 결과는 문헌 [Moser and 
Niers 仕 asz, 1996] 에 서 론의하였 다. IEEE Software 외 1996 년 7 월 호에 는 대 규모프로젝 트들 
의 관리에 대한 수많은 기사들이 들어 있다. 이러한것들로서는 문헌 [Charette, 1996] 이 
있는데 이 것은 대 규모프로젝 트들을 관리하는데 관계되는 위 험 들을 론의하였 다. 위 험 관리 
에 대한 또 다른 기사는 문헌 [Gemmer, 199 刀이다. IEEE Compute ) ，의 1996 년 9 월호에는 
객체지향프로젝 트들의 관리 에 대 한 기 사들이 들어 있다. 특별한 관심사로 되는것은 문헌 
[Sparks, Benner, and Faris, 1996, and Williams, 1996] 이 다. 

쏘프트웨 어프로젝 트관리계 획을 위한 IEEE 규격 1058.1 에 관한 보충적 인 정보를 얻 자면 
규격 그자체를 자세 히 보아야 한다 [IEEE 1058.1, 1987]. [Sackman, Erikson, amd Grant, 
1968] 에 는 새 크맨 (Sackman) 의 저서 가 서 술되 여 있다. 보다더 구체적 인 문헌은 [Sackman, 
197 이이 다. 문헌 [Shepperd and Ince, 1994] 를 비 롯하여 쏘프트웨 어 과학에 대 한 많은 비 판 
적 인 개 관들이 발표되 였다. 기능점들에 대 한 정보는 문헌 [Low and Jeffrey, 1990] 에서 
찾아 볼수 있다. 기능점에 대한 개선된 세밀한 분석은 문헌 [Symons, 1991] 에서 고찰하 
였다. 기 능점 들에 대 한 비 평 들이 문헌 [Kitchenham, 199 刀에 서 고찰하였 다. 다른 분석 들 
은 문헌 [Jeffrey, Low, and Barnes, 1993, and Kitchenham and Kansala, 1993] 에 있다. 비 
용타산공정 을 개선하기 위한 제의는 문헌 [Lederer and Prasad, 1992] 에서 론의하였 다. 기 
능점 들의 우점 과 약점 들은 문헌 [Furey and Kitchenham, 199 기에 서 지 적 하였 다. 기 능점 의 
모든 측면에 대한 정보는 문헌 [Boehm, 199 기에서 종합적으로 주었다. 

중간 COCOMO 를 실현하기 위한 구체적 인 세부들과 함께 그것을 위한 리론적 인 조정 
은 문헌 [Boehm, 1981] 에 있다. 보다 짧은 판본은 문헌 [Boehm, 1984b] 에서 설명하고 있 
다. COCOMO II 는 [Boehm et al„ 200 이에 서 고찰하였 다. 

문헌 [Myers, 1989] 는 아주 큰 쏘프트웨 어 프로젝 트들을 위 한 개 발시 간을 타산하기 
위한 척 도에 관한 정 보를 제 공해 주고 있 다. 다양한 업 무자료처 리 제 품들을 위한 쏘프트 
웨 어생산성 자료가 문헌 [Maxwell and Forselius, 2000] 에 제시되 여 있다. 리 용된 생산성의 
단위 는 시 간당 기 능점 수들이다. 주어 진 제 품의 문서 페지 수들을 평 가하기 위한 공식 은 
문헌 [Jones, 1994b] 에서 서술하였다. 
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문 제 

9.1. 일 부 쏘프트웨 어 기 업 체 들 이 왜 리 정 표 ( milestone ) 를 무거 운 짐 { millstone ) 이 라고 
말한다고 생각하는가? 

9.2. 당신은 네더버그쏘프트웨어개발회사에 있는 쏘프트웨어공학자이다. 한해전에 당 
신의 경영자는 당신의 다음제품이 9 개의 파일들， 49 개의 흐름， 87 개의 공정들을 포함할 
것이라고 발표하였다. 

(1) FFP 척 도를 리용하여 그 크기 를 확정하시 오. 

(2) 네더버 그쏘프트웨 어개 발회사를 위해 식 (9.2) 에 있는 실수 d 는 932 딸라 된다 
고 확정되였다. FFP 척도는 비용타산을 얼마로 예측했는가? 

(3) 최근에 제품이 134,500 딸라의 비용으로 완성되였다. 이것은 개발림의 생산성 
에 대해 무엇을 말해 줄수 있는가? 

9.3. 목적하는 제품에는 7 개의 단순한 입력， 11 개의 보통의 입력 그리고 8 개의 복잡 
한 입력들이 있다. 40 개의 보통출력들， 5 개의 단순한 질문들， 18 개의 평균주파일들 그리 
고 12개 의 복잡한 대 면부들이 있 다. 조절되 지 않는 기 능점 들 ([/ FP ) 을 결정하라. 

9.4. 만일 문제 9.3 의 제 품을 위한 총체 적 인 영 향의 정 도가 49 이 라면 기 능점 들의 수 
를 결 정하라. 

9.5. 당신은 그의 약점에도 불구하고 왜 코드행들 ( Loc 혹은 KDSI ) 이 제품크기의 척도 
로 그렇 게 널 리 리용된 다고 생 각하는가? 

9.6. 당신은 자료기 지 의 크기 가 대 단히 높다고 타산하고 쏘프트웨어 도구들의 리용이 
낮은것으로 타산된것을 제외 하고 명목상인 79-KDSI 가 내장된 제품을 개 발하는것을 책 임 
졌 다. 중간 COCOMO 를 리용하면 월공수로 평 가된 노력 은 얼 마인가? 

9.7. 당신은 두개의 45-KDSI 단순한 방식의 제품을 개발할 책임을 졌다. 제품 P1 
가 특별히 높은 복잡성을 가지고 있고 제품 P2 이 특별히 낮은 복잡성을 가지고 있는 
것 외 에 모든 측면 에 서 그것 들은 둘 다 명 목상이다. 제 품을 개 발하기 위하여 당신은 
바라던대로 2개의 림을 가지게 된다. 림 A 는 대 단히 높은 분석능력과 응용경험 그리 
고 프로그람작성능력 을 가지 고 있다. 림 A 는 또한 높은 가상기 계숙련과 프로그람작성 
언어경험을 가지고 있다. 림 B 는 5 개의 모든 속성들에 한에서 대단히 낮은 수준으로 
평가된다. 

(ᄀ) 만일 림 A 가 제품 미를 개발하고 림 B 가 제품 P 2 을 개발하다고 하면 총체적 
인 노력은 월공수로 얼마인가? 

(1_) 만일 림 B 가 제품 마를 개발하고 림 A 가 제품 P 2 을 개발한다면 전체 노력은 
월공수로 얼마인가? 
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( C ) 두개의 선행한 성원배치들중에서 어느 배치가 더 의미 있는가? 당신의 직감 
이 COCOMO 의 예측의 지지를 받고 있는가? 

9.8. 당신은 모든 측면에서 명목상인 54-KDSI 단순한 방식의 제품을 개발할 책임을 
졌 다. 

(1) 평균월공수당 9,400딸라의 비용을 가정하면 타산된 프로젝트의 비용은 얼마인 
가? 

(2) 당신 이 전체 개발림 을 프로젝 트의 시 발점 에 서 단념하였 다. 당신은 운이 좋아 
명목상의 림을 대단히 경험이 많고 능력이 있는 림으로 교체할수 있었다. 그 
러나 평균 월공수당 비용이 12,200딸라로 오를것이다. 

당신은 인원변동의 결 과로 얼 마나 많은 돈을 벌 게 된 다고(혹은 손해보리 라고) 
기 대 하는가? 

9.9. 당신은 큰 화물차운송회 사를 위해 가장 비 용이 효률적 인 로정 을 계 산하기 위한 
쏘프트웨어제품을 새롭게 연구된 알고리듬을 리용하여 개발할 책임을 지고 있다. 중간 
COCOMO 을 리용하여 당신은 제 품의 비 용이 430,000딸라일것 이 라는것 을 확정한다. 그러 
나 시 험하여 당신은 림 의 한 성원에 게 기 능점 들을 리용한 노력 을 평 가해 보라고 요구한 
다. 그는 기 능점척 도가 당신의 COCOMO 예 측보다 수배 씩 이 나 더 큰 890,000딸라의 비 용 
을 예측하였다고 보고한다. 이제 당신은 무엇을 하는가? 

9.10. 레 이레그분산(식 (9.9)) 이 살ᄐ 소일 때 최대값을 얻는다는것을 보여 준다. 해당한 
자원소비를 찾으시오. 

9.11. 제품유지정비계획이 IEEE SPMP 의 《추가적인 구성요소》이라고 생각한다. 모 
든 중요한 제품들이 유지정 비되고 유지정 비비 용이 평균 제품을 개 발하는 비용의 두배 나 
된다는것을 생각하면 이것을 어떻게 조절하겠는가? 

9.12. (과정 안상 목표) 부록 1 에 있는 브로드렌즈지 역 아동병 원프로젝 트를 생 각해 보 
자. 순수 부록 1에 있는 정보에 기초하여 비용과 기간을 타산하는것이 왜 가능하지 못한 
가? 

9.13. (쏘프 트웨 어 공학독본) 교원은 문헌 [ Nesi , 1998] 의 복사본을 나누어 줄것 이 다. 
당신은 객체지향쏘프트웨어제품들을 관리하는 가장 도전적 인 측면들이 무엇 이 라고 생 각 
하는가? 
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제 2 편 

쏘프트웨어생명주기의 단계 

제2편에서는 쏘프트웨어생명주기의 단계들에 대하여 깊이 있게 서술한다. 매 단계들 
에 대하여 그 단계의 설명요구뿐만아니 라 그에 고유한 CASE 도구들, 척도 및 시험 기법들 
이 제시된다. 

제10장에 서 는 요구사항확정단계 에 대 하여 고찰한다. 이 단계 의 목적 은 의 뢰 자의 
실제의 요구를 확정하는것 이 다. 이 목적 을 달성 하기 위한 한가지 기 법은 신속원형작 
성 법 이 다. 이 장에 서 각이한 류형 의 신속원형작성 법 과 기 타 요구분석기 법 들이 고찰 
된 다. 

일단 요구가 결정되면 그 다음단계는 명세서를 작성하는것 이 다. 여기에 대 하여서는 
제 11장《명세작성단계》에서 고찰한다. 명세작성에 관한 기본방법들인 비형식적，준형식 
적 및 형식 적명세작성 방법들이 제 시되며 매 방법들에 대 한 실례들도 서술된다. 구조화체 
계 분석, 유한상태기계，페트리망을 포함한 기 법들이 깊 이 있게 서술되 고 실례연구에 의하 
여 례 증되 며 여 러 가지 기 법 들에 대 한 Z . A 비 교를 제 시한다. 

제11장에서 서술하는 모든 명세작성기법들은 구조화파라다임에 근원을 두고 있다. 
객 체 지 향명 세 작성 법 은 제 12장 《 객 체 지 향분석 단계》에 서 서 술한다. 이 객 체 지 향명 세 작성 
기 법은 앞장에서 고찰한 구조화명세작성 기법의 변종으로서 제시된다. 

제13장 《 설계 단계》에서 는 객체지향설계뿐만아니 라 자료호출분석, 트랜잭 션업무분 
석 과 같은 고전적방법 들을 포함하여 여 러 가지 설 계 방법 들을 비 교한다. 이 장에 서 는 특히 
실례연구를 포함하여 객체지향설계 에 주목을 돌리며 비 교와 대조에 중점 을 둔다. 

실현과 관련한 론의는 제14장과 제15장에서 진행된다. 제14장은 실현단계를 고찰하 
고 있는데 여기에는 프로그람작성언어의 선택, 4세대프로그람언어，좋은 프로그람작성관 
계, 프로그람작성규격 들이 포함된다. 실현단계 와 통합화단계 는 병 렬로 수행되 여 야 하는데 
이것은 제15장《실현 및 통합단계》의 주제로 된다. 

계2편은 제16장 《 유지정 비단계》로 결속된다. 제16장의 기본화제는 유지정 비의 중 
요성 과 설 명 요구이 다. 유지 정 비 에 관한 관리 문제 가 약간 자세하게 고찰된 다. 제 2편을 결 
속하면서 쏘프트웨 어개 발공정 의 모든 단계 들과 그 매 개 단계 와 관련된 요구들, 이 요구 
를 만족시 키 기 위한 방도들에 대 하여 명백한 리해를 가지게 될것 이 다. 
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제 1 0장. 요구사항확정단계 


쏘프트웨 어 개 발림 성 원들이 어 떤 쏘프트웨 어제 품의 사명 에 대 하여 동의 하지 않는 
한에서는 그 제품이 주어 진 운영비범위내에서 제기간에 개발될 가능성이 거의 없다. 
이와 갈은 합의를 이룩하기 위한 첫단계는 의뢰자의 현재상황을 될수록 정확히 분석 
하는것이다. 실례로 《의뢰자들움 자기들이 가지고 있는 수동설계체계가 락후하기때 
문에 를퓨터지원설계체계를 요구한다.》고 말한다면 그것은 적당치 않다. 그것은 개 
발림이 현재의 수동체계가 가지고 있는 결함을 정확히 알지 못하는 한에서는 새로운 
콤퓨터화된 체계의 상황 역시 《 락후》해 질 가능성이 크기때문이다. 이와 류사하게 
만일 어떤 개인용콤퓨터제조업자가 새로운 조작체계를 개발하려고 하는 경우 그 첫 
단계는 회사의 현존조작체계를 평가하여 그것이 왜 불만족스러운가를 주의 깊게 정확 
히 분석하는것이다. 극단적인 실례를 든다면 문제가 판매업자의 심중에만 존재하는가， 
누가 그 조작체계의 불매에 대하여 비난하는가，그 조작체계의 사용자들이 그 체계의 
가능성과 신뢰성에 대한 환상에서 깨여 났는가를 아는것은 극히 사활적 인 문제로 된 
다. 현재의 상황을 명백히 리해하여야만 개발림은 새 제품이 무엇을 할수 있는가 하 
는 중대한 문제에 답변할수 있다. 이 문제에 대한 답변과정은 요구사항확정단계에서 
수행되게 된다. 

일반적으로 생기는 오해는 요구사항확정단계에서 개발자들이 의뢰자가 무슨 쏘프트 
웨어를 원하는가를 결정하여야 한다고 하는것이다. 이와 달리 요구사항확정단계의 실지 
목표는 의뢰자가 무슨 쏘프트웨어를 필요로 하는가를 결정하는것이다. 문제는 바로 많은 
의뢰자들이 자기들이 무엇을 필요로 하는가를 모르고 있다는데 있다. 더우기 대부분의 
의 뢰 자들은 개 발림 성 원들보다 콤퓨터 에 조예 가 깊지 못하기 때 문에 무엇 이 필요되 는가에 
대 한 훌륭한 착상을 가지고 있는 의뢰자조차 자기의 착상을 개발자에게 정확히 전달하기 
어려울수도 있다. 

1967년에 미 국의 대통령 후보자 죠지 롬니 (George Romney ) 는 자기 의 발언에서 한번에 
너무 많은 실수를 하였다. 그는 어느 한 기자회견을 소집하고 다음과 갈은 설명을 발표 
하였던것이다. 

《 내 생 각에 는 당신 이 내 가 말한것 을 자기 가 리해하였 다고 믿 고 있 는것 같은데 내 
생각에는 당신이 자기 가 들은것 이 내가 말하려고 하였던것 이 아니 라는것을 깨 닫지 못한 
것 갈다.》 

이 와 같은 변명 은 요구분석에서도 그대 로 적 용된다. 즉 개 발자들은 의뢰 자들의 요구 
를 듣지만 그들이 듣는것은 의뢰자가 말하는것 이 아니 다. 

계3장에서 는 이 와 갈은 정 보전달에 의한 문제 를 해 결 하기 위한 한가지 방도가 신속 
원 형작성 을 진행하는것 이 라는것 을 지 적하였 다. 이 장에 서 는 요구사항확정단계 를 더 욱 자 
세히 서 술하며 각이한 요구분석기 법 들의 장점 과 약점 들에 대 하여 론의한다. 

먼저 요구도출문제부터 고찰하기로 한다. 
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10. 1 . 요 구 도 출 


의뢰자의 요구를 발견하는 과정을 요구도출(또는 요구포착)이라고 부론다. 일단 초기 
요구모임이 결정되면 그것을 세련시키고 확장하는데 이 과정을 요구분석이라고 부론다. 
요구사항확정단계 는 일 반적 으로 한명 또는 그이상의 요구사항확정림성 원들이 목적 하는 
제품에서 무엇이 필요한가를 결정하기 위하여 한명 또는 그이상의 의뢰자들과 면담하는 
것으로부터 시작된다. 

의뢰자의 요구를 도출하기 위하여서는 요구사항확정림성원들이 응용령역 즉 제안된 
쏘프트웨어제품이 리용되게 될 일반령역에 정통하여야 한다. 례를 들어 은행경영이나 병 
간호에 대하여 먼저 일정한 정도로 정통함이 없이 은행일군이나 간호원에게 의미 있는 
문제를 제기한다는것은 쉽지 않다. 그러므로 요구분석 림의 매 성원들이 선차적으로 해야 
할 일은 자기가 해당 일반령역에 대한 경험이 없는 한에서는 그 응용령역에 정통하는것 
이다. 목적하는 쏘프트웨어에 대한 의뢰자와 잠정적인 사용자들과 정보교환을 진행할 때 
정확한 용어를 사용하는 문제가 특별히 중요하다. 결국 면담자들이 그 령역에 고유한 전 
문술어를 리용하지 않는다면 어떤 전문령역에 종사하는 사람들과 진지하게 작업하기가 
어려워 진다. 보다 중요하게는 부적당한 용어들의 리용은 오해를 산생시켜 결국은 오작 
제품이 배포되는데로 이어 질수도 있다. 실례로 비전문가에게는 버림대, 들보, 대들보, 지 
주목과 같은 단어들이 동의어처럼 생각되지만 토목기사에게는 이 단어들이 서로 차이나 
는 용어 들이 다. 만일 개 발자가 토목기 사가 이 4개 의 용어 를 정 확히 구분하여 리용하고 
있다는것을 식별하지 못한다면 그리고 만일 토목기사가 개발자는 이 용어들사이의 차이 
를 알고 있 다고 가정 하고 있 다면 개 발자는 이 4개용어 들을 같은것 으로 취 급할수도 있 다. 
결 국 콤퓨터 지원교량설 계 프로그람은 다리 붕괴 를 초래할수 있는 오유를 포함하게 된 다. 
콤퓨터전문가들은 매 프로그람에 기초해서 결심이 체택되기전에 그 프로그람의 결과들이 
자세히 조사되기를 바란다. 그러나 콤퓨터에 대한 대중적인 신뢰가 증대되고 있는 현실 
은 이와 갈은 검사가 진행될 가능성 에 의거하는것 이 명백 히 어리석 은 일 이 라는것을 말해 
주고 있다. 그러 므로 전문술어 에서의 오해 가 쏘프트웨 어개 발자들의 무책 임성 을 고소하는 
데로 이어 질수 있다고 생각하는것은 의미가 없다. 

전문술어와 관련된 이 러한 문제를 해결하기 위한 한가지 방도는 용어해설집을 만드 
는것 이 다. 요구사항확정림 이 응용령역 에 대 하여 학습하는 과정 에 초보적 인 용어 들이 용 
어해 설집 에 들어 간다. 그다음 용어 해 설 집 은 요구사항확정림 성 원들이 새 로운 술어 를 만 
날 때마다 갱신된다. 이와 갈은 용어해설집은 의뢰자와 개발자사이의 혼돈을 줄일뿐만아 
니 라 개발림 성 원들사이 의 오해 를 줄이 는데 도 유익하다. 

일단 요구사항확정림이 령역에 정통하게 되면 그 다음단계는 의뢰자의 요구에 대한 
결정 을 시 작하는것 즉 요구도출을 진행하는것 이 다. 1차적 인 도출기 법 은 면담을 진행하는 
것 이 다. 


10. 1 . 1 .면담 

요구사항확정 림성 원들은 자기들이 의 뢰 자와 미 래의 제 품사용자들로부터 련관된 정 보 
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를 모두 도출하였다고 확신할 때까지 의뢰자림성원들과 면담을 진행해야 한다. 면담에는 
두가지 기본형식 즉 구조화된 면담과 비구조화된 면담이 있다. 구조화된 면담에서는 전 
문적이면서 미리 계획되고 고정된 문제들이 제출된다. 실례로 의뢰자는 회사가 몇명의 
판매원을 고용하고 있는가, 얼마나 빠른 대답시간을 요구하는가 하는 문제를 제기할수 
있다. 비구조화된 면담에서는 면담대방이 말을 하도록 하면서 고정되지 않은 문제들이 
제출된다. 실례로 의뢰자에게 《왜 현재의 제품이 만족스럽지 못합니까?》라고 묻는다면 
의뢰자는 업무와 관련한 많은 상황을 설명할수도 있다. 이러한 일부 사실들은 만일 면담 
이 구조화된 경우에는 드러나지 않을수도 있는것들이다. 

이와 동시에 면담을 지나치게 비구조화하는것은 좋은 방법이 아니다. 의뢰자에게 
《현재의 제품에 대 하여 말하시 오.》라고 말한다면 적 당치 못한 정 보들을 많이 만들어 
내게 될것이다. 그러므로 질문은 면담대방이 면담자가 요구하는 정보범위내에서 폭 넓은 
답변을 줄수 있도록 유도하는 방식으로 제시되여야 한다. 

면담을 솜씨 있게 이끌어 나가는것은 언제나 쉬운것은 아니다. 첫째로, 면담자는 응 
용령역에 정통하여야 한다. 둘째로, 면담자가 이미 의뢰자의 요구를 파악하였다면 의뢰자 
림의 어떤 성원과 면담할 때 아무런 리득도 엄지 못한다. 면담자는 비록 다른 수단에 의 
하여 이미 듣었거나 알았다고 하여도 의뢰회사나 의뢰자들의 요구 그리고 구성하려는 제 
품의 잠정적 리용과 관련하여 이미 알고 있는 개념들을 될수록 나타내지 않으면서 면담대 
방이 말해 야 할것 을 주의 깊게 듣는 방향애서 매 면담에 대 하여 야 한다. 

면담이 계속되면 면담자는 면담결과를 제시하는 서면보고서를 준비하여야 한다. 
면담대방에게 보고서의 부본을 반드시 주어야 한다. 왜냐하면 면담대방이 문장내용을 
명백히 하거나 주요 항목들은 흙어 보려고 할수도 있기때문이다. 

1 0. 1 . 2. 대본작성 

대본작성은 요구분석을 진행하는 또 한가지 기법이다. 대본작성은 사용자가 일정한 
목적을 달성하기 위하여 목적하는 제품을 활용할수 있게 하는 방법이다. 실례로 목적하 
는 제품이 몸까기계획프로그람이라고 하자. 하나의 가능한 대본은 영양학자가 환자의 나 
이，성별，무게，키 기타 개인자료를 입력할 때 무엇이 발생하는가를 서술하는것이다. 프 
로그람은 그다음 그 환자에 대한 표본차림표를 찍어 낸다. 이 대본이 미래의 프로그람사 
용자에게 제시될 때 영양학자는 그 차림표가 당뇨병환자，채식주의자，유당을 싫어 하는 
사람들과 갈은 특수한 음식요구를 가지고 있는 환자들에게 적당치 않을 수도 있다는것을 
재빨리 지적한다. 개발자는 임의의 식사차림표를 찍어 내기에 앞서 사용자가 특수한 음 
식을 요구할수 있도록 이 대본을 수정한다. 대본의 리용은 사용자로 하여금 자기들의 수 
요를 요구분석자들에게 전달할수 있도록 한다. 

몸까기계획작성프로그람의 실례에서 나아가서 이 프로그람이 영양학자가 환자의 키 
를 센치메터로 입력할 때 그것을 인치로 내보낼것을 요구한다고 가정하자. 이것은 하나의 
례외 실례 이 다. 대본은 기대 하는 사건렬들뿐만아니 라 모든 례외적 사건들도 포함하여 야 한 
다. 대본은 각이한 방식으로 묘사될수 있다. 한가지 기법은 대본을 구성하고 있는 작용들 
을 단순하게 렬거하는것이다. 이것은 11장에서 설명한다. 또 한가지 기법은 문서화상적재 
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판 즉 사건렬을 묘사하는 선도를 설정하는것이다. 문서화상적재판은 문서원형 [ Retti 뱀, 
1994] 즉 련관된 화면과 사용자의 답변을 묘사하고 있는 종이판별 로 생 각할수 있 다. 

그러 나 무슨 방법 이 선택되 든지간에 대본은 출발상태, 기대하는 사건렬，최종상태， 
기 대 하는 사건에 례 외적 인 사건들을 모두 묘사하여 야 한다. 

대본은 다른 여 러 가지 방법들에서도 쓸모 있다. 

1. 대본은 제품의 거동을 사용자에게 알기 쉬운 방식으로 보여 줄수 있다. 이것은 
몸까기계 획프로그람에서처 럼 추가적 인 요구를 드러 내 게 할수 있다. 

2. 대 본은 사용자들이 리해할수 있기 때 문에 대 본의 활용은 의 뢰 자와 사용자들이 요 
구분석 과정 의 전반에 걸 쳐 능동적 인 역 할을 놀수 있게 한다. 결 국 요구분석단계 
의 목표는 의 뢰자의 실 제 적 요구를 도출하는것 이 며 이 러한 정보의 유일 한 원 천 은 
의뢰 자와 사용자들이 다. 

3. 대 본(또는 보다 정 확하게 는 리용실례)은 객체지향분석 에서 중요한 역 할을 논다. 
이에 대하여서는 12.3 에서 자세히 서술한다. 

이 제 요구도출에 관한 기 타 기 법 들을 고찰하기 로 하자. 

10. 1 . 3. 기타 요구도출기법 

요구를 도출하기 위한 다른 방법은 질문서를 련관된 의뢰기구성원들에게 보내는것이 
다. 이 기법은 수많은 개별적사람들의 견해를 결정할 필요가 있을 때 유용하다. 더우기 
주의 깊게 생각해 낸 서면답변은 면담자가 제기한 질문에 구두로 즉시에 답변하는것보다 
더 정확할수 있다. 그러나 면담자가 초기답변을 주의 깊게 듣고 그것을 확장한 질문을 제 
기하는 방법으로 진행해 나가는 비구조화된 면담은 일반적으로 주의 깊게 작성된 질문 
서보다 훨씬 더 좋은 정보를 준다. 질문서는 사전에 계획되기때문에 질문이 답변에 따라 
제안될 방도는 없다. 

특히 기 업환경 에서 요구를 도출하는 또 다른 방법은 의뢰 자가 리용하는 각이 한 형식 
을 조사하는것이다. 실례로 어떤 출판사에서 리용하고 있는 출판형식은 출판량, 종이로라 
크기, 습도, 잉크온도, 종이의 장력 등을 반영할수도 있다. 각이한 분야들에서 이 형식을 
리용하여 인쇄작업의 흐름과 련관된 출판공정에서의 중요한 단계들에 개선을 가져 올수 
있다. 조작절차와 일반서술과 갈은 기타 문서들도 무엇을 어떻게 수행해야 하는가를 찾 
아 내기 위한 강력한 수단으로 될수 있다. 의뢰자가 현재 어떻게 경영해 나가고 있는가 
를 고려하고 있는 이와 같은 종합적인 정보는 의뢰자의 요구를 결정하는데서 특별히 도 
움이 될수 있다. 그렇기때문에 의뢰자의 문서작성은 주의 깊게 음미해 보는 과정을 절대 
로 홀시하지 말아야 한다. 왜냐하면 그것이 의뢰자의 요구를 정확히 판단할수 있게 하는 
하나의 정보자원으로 되기때문이다. 이와 같은 정보를 획득하기 위한 보다 새로운 방법 
은 작업장안에 비데오카메 라를 설치하고 그 곳에서 진행되고 있는 과정을 정확하게 기록 
하는것이다. 이 방법을 적용하는데서 나서는 한가지 어려운 문제는 레프를 분석하는데 
오랜 시간이 걸린다는것이다. 일반적으로 한명 또는 그이상의 요구분석성원들은 카메라 
가 한시간동안 기록한 레프를 재생하는데 한시간을 소비하여야만 한다. 이 시간에 관측 
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된것을 평가하는데 필요한 시간이 더 합쳐 진다. 보다 심중하게는 종업원들이 카메라를 
자기들의 사생활에 대한 부당한 침해로 볼수 있기때문에 이 기법은 나쁜 결과를 초래하 
는것으로 알려 져 있다. 

중요한것은 요구분석림이 모든 종업원들과 충분히 협동하는것이다. 만일 사람들이 
협박을 받는다든가, 괴로움을 겪는다고 느끼게 되면 필요한 정보를 획득하는것은 매우 
어렵다. 카메라를 도입하기전에 있을수 있는 위험을 주의 깊게 고찰하여야 하며 또는 그 
러한 문제가 생긴 경우에는 성난 종업원들을 진정시킬수 있는 다른 임의의 방법을 취하 
여야 한다. 일단 초기요구모임이 얻어 지면 그 다음단계는 그것을 실현시키는것인데 이 
과정 을 요구분석 이 라고 부론다. 

10. 2. 요 구 분 석 

이 단계에서 요구사항확정림은 하나의 예비요구모임을 가지게 된다. 이러한 요구들 
에는 두가지 류형 즉 기능적요구와 비기능적요구들이 포함된다. 기능적요구들은 목적하 
는 쏘프트웨어의 기능성과 관련되여 있다. 실례로《매 배우들의 공연료금은 1998년 5월 
에 제정한 CMS 공식을 리용하여 공연목록자료로부터 계산될것 이 다.》를 들수 있다. 비 기 
능적명세서는 믿음성과 유지정비성과 같은 목적한 쏘프트웨어의 성질을 규정하거나 쏘프 
트웨 어 가 실행될 환경과 관련되 여 있다. 실례 로《 모든 막대코드 (Zw coc / e ) 들은 Mach/Zor 
나 ASRCA 입 력 장치 를 리용하여 읽 혀 질것 이다.》를 들수 있 다. 

쏘프트웨어 가 추적 가능해 야 한다는것은 본질적 인 문제 이 다. 즉 명세서，설계, 코드를 
포함하여 요구문서안의 매 문장들은 추적할수 있 어 야 한다. 이 런 방식 으로 SQA 그룹은 
요구문서안의 매 문장이 실 현되 였는가 그것 이 정 확히 수행 되 였는가를 검 사할수 있 다. 추 
적가능성 을 실 현 하기 위 하여 서 는 요구문서안의 매 문장에 번 호를 매 길 필 요가 있 다. 

예 비요구문서안의 모든 항목들令 우선권을 가지도록 의뢰 자에게 제공된다. 의뢰 자 
(또는 의 뢰 자림 )는 본질 적 인것，몹시 필 요한것 , 필 요한것 등등의 범 주를 리용하여 매 개 
의 예 비 요구들을 분석한다. 이 과정 을 진행하는 기 간에 어 떤 요구들은 부정 확하거 나 
상관이 없다는것이 명백해 질수 있는데 이러한 요구들을 교정하거나 삭제한다. 다음 
단계 는 예 비 요구문서 를 더 욱 세 련 시키 는것 이 다. 

우선 요구사항확정림 성 원들은 무엇 을 생 략하겠는가를 검 정하기 위하여 각이한 개 별 
적면담대방들과 요구문목록을 토의한다. 그다음 가장 정 확하고 강력한 요구분석기법은 
신속원형작성 방법이 기 때 문에 하나의 신속원형 을 작성한다. 이 에 대 하여 다음절 에서 고찰 
한다. 


1 0. 3. 신속원형작성방법 

신속원형작성은 쏘 프트웨 어를 신속히 작성하는것인데 그것은 목적하는 제품의 중요 
한 가능성들을 보여 준다. 실례로 종합주택의 관리를 지원하는 쏘 프트웨 어는 사용자가 
새 거주자에 대한 세부사항을 입력 할수 있게 하는 입력화면과 매달 거주보고서를 인쇄하 
는 기능을 병합하여야 한다. 이러한 상황들이 신속원형작성에 병합된다. 그러나 오유검 
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.능력，파일갱신부분프로그람，주택사용료금계산들은 포함되지 않을수도 있다. 관건적 
문제는 하나의 신속원형이 입력화면이나 보고서와 갈은 의뢰자가 볼수 있는 기능성1 
- 반영하지만 파일갱신과 같은《은폐》된 상황들은 생 략하고 있다는것이 다(신속원형직 
법을 고찰하는 다른 방법에 대하여서는 다음의 《알고 싶은 문제》를 보시오.). 

알:2 싶 a ©제 

어떤 제품의 중요한 측면을 보여 줄 목적으로 모형을 구성할데 대한 착상은 요 버전에 
나왔다. 실례 로 도메 니 코 크레 스리 (Domenico Cresti; 그는 이 딸리 아의 치 안터 구역 피 자 그나 
노읍에 서 출생하였 기 때 문에 《 II파씨그나노》로 알려 져 있 다.)가 1618년 에 그린 그* 은 미 
겔 란젤로가 로마법 왕 파울로 4세 에 게 중정한 로마의 페 터스거'리 에 대 한 나무로 만든 설계모 
형을 보여 주고 있다. 이러한 건축모형은 규모가 방대하였다. 즉 건축가 브라만테 (Br mante) 

가 작성한 앞선 설계계획은 한면의 길이가 20피트이상에 달하였다. 

건축모형 은 각이한 목적 에 많이 리 용되 였다. 우선 크레 스리 가 그린 그림 에서 S 같이 
모형은 어떤 프로젝트에 자금을 투자하는데 의뢰자의 관심을 끌도록 하는데 리용 ᅵ였다. 
이것은 신속원형 을 의 뢰 자의 실지 수요를 결정하는데 리용하는것과 류사하다. 다음- .로 건 
축설계가 진행되기 이전시대에 모형은 건축가들에게 건물의 구조를 보여 주고 석공 들에게 
는 건물을 어떻게 장식해야 하는가를 지적하는데 리용되였다. 이것은 10.4 에서 설명 &바와 
같이 사용자대면부에 대한 신속원형을 작성하는 방법과 류사하다. 

그러 나 건축모형과 쏘프트웨어의 신속원형 을 지 나치 게 밀접 히 비 교하는것은 그 i 좋지 
는 않다. 신속원형 은 의 뢰 자의 요구를 도출하기 위하여 요구사항확정단계 에 서 러 i ■된다. 
건축모형 과는 달리 신속원형 은 건축설계 나 세부구조를 제 시하는데 는 리 용되지 않수 다. 설 
계는 두단계 지나서 즉 설계 단계 에서 만들어 진다. 

제 품의 의 뢰 자와 예 정된 사용자들은 신속원형 으로 실험 을 진행하며 한편 개발림성 원 
-은 요점을 찾아 쥔다. 자기들의 경험에 기초하여 사용자들은 개발자들에게 신속원형이 
-기들의 요구를 얼마나 만족시키는가를 말하며 보다 중요하게는 개선할 필요가 있는 부 
-들을 찾아 낸다. 개발자들은 의뢰자의 요구들이 신속원형에 정확하게 교갑된다는것4 
: 측이 확증할 때까지 신속원형을 변화시킨다. 그다음 신속원형은 명세서를 작성하기 위 
: 기초로 리용된다. 

신속원형 작성모형의 중요한 측면은《조기》라는 말에 구현되 여 있다. 궁극적으로는 
.형을 가능한대로 빨리 작성하는것 이 다. 결국 신속원형작성의 목적은 의뢰자가 제품에 
하여 더빨리 더잘 리해하도록 하는것이다. 신속원형이 힘들게 동작하고 그것이 매번 
분간 폭주되거나 화면설계가 완전하지 못하다 하여도 문제로 되지 않는다. 신속원형직 
의 목적은 의뢰자와 개발자가 그 제품이 해야 할바에 대하여 될수록 빨리 합의할수 있 
-록 하는것이다. 그렇기때문에 신속원형에서의 임의의 불완전한 측면들은 그것들이 신 
•원형의 기능성을 심히 손상시키지 않으며 또한 쏘프트웨어제품의 동작에 대하여 그릇 
. 표상을 주지 않는다는 조건하에서 무시될수 있다. 

신속원형작성모형의 두번째로 중요한 측면은 신속원형을 변화시킬수 있도록 작성히 




여야 한다는것이다. 만일 신속원형의 첫번째 판본이 의뢰자가 요구하는것이 아니라면 그 
원형은 의뢰자의 요구를 더잘 만족시키는 두번째 판본으로 신속히 전환되여야 한다. 신 
속원형 작성 전 과정 에 걸처서 개 발을 신속하게 진행 하기 위하여 Smalltalk , Prolog , Lisp 와 
같은 4세 대프로그람언어 (4 GLs ) 들과 해 석 형 언어들을 리용한다. 현재 광범히 리용되 고 있 
는 신속원형작성언 어 들로는 visual C ++ 와 J ++ 뿐만아니 라 HTML 들과 Perl 도 들수 있 다. 일 
부 해석형언어들에 주의가 돌려 졌지만 고전적인 원형작성이라는 관점에서 보면 이것은 
적 당하지 못하다. 문제 점 은 다음과 같다. 어 떤 주어 진 언어 가 신속원형작성 에 리용될수 
있는가? 신속원형은 재빨리 변화될수 있는가? 만일 이 두가지 질문에 대한 답변이 긍정 
이 라면 그 언어 는 신속원형작성 을 위한 후보로서 적 당하다고 할수 있다. 

이제 신속원형 을 객체지향모형과 결합하여 사용하는 방향으로 전환하여 보면 IBM 회 
사가 진행한 세 가지 서 로 다른 객체 지향프로젝 트들은 구조화된 모형 을 리용하는 프로젝 
트들에 비 하여 뚜렷 한 개 선을 보여 주었 다 [ Capper , Colgate , Hunter , and James , 1994]. 

이와 갈은 프로젝트들로부터 얻게 되는 한가지 문제는 객체지향생명주기에서 될수록 
빨리 신속원형 을 작성하는것 이 중요하다는것 이 다. 

신속원형은 어 떤 쏘프트웨어제품에 대 한 사용자대면부를 개 발할 때 에도 매우 효과적 
이다. 이러한 리용방법과 관련해서는 다음 절에서 고찰한다. 

1 0. 4. 인간적인자 

쏘프트웨어제품의 의뢰자와 미래의 사용자가 모두 사용자대면부에 대한 신속원형과 
호상작용한다. 사용자들이 인간 콤퓨터대면부 ( HCI ) 로 실험하도록 하는것은 최종제품이 
변경될 위험성을 크게 감소시 킨다. 특히 이 러한 실험은 모든 쏘프트웨어제품들의 사활적 
목적 인 사용자친절성 을 달성할수 있게 한다. 

사용자친절성 이 라는 술어 는 인간이 쏘프트웨어제 품과 쉽 게 정 보교환을 할수 있다 
는것 을 의 미한다. 만일 사용자가 쏘프트웨어제 품을 사용하는 방법 을 배 우기 어 렵거 나 
화면이 혼돈되거 나 번거 럽다고 느끼게 된다면 사용자는 더는 그 제품을 리용하지 않거 
나 잘못 리용하게 될것이다. 이러한 문제를 해소하기 위하여 차림표구동프로그람이 도 
입되 였다. 즉《계산을 수행하시 오.》든가《 봉사료금에 관한 보고서를 인쇄하시 오.》 
와 갈은 명령을 입력하는것 대신에 사용자는 다음과 갈은 가능한 응답모임들가운데서 
단순한 선택 만 진행하면 된다. 

1. 계 산을 수행하시 오. 

2. 봉사료금에 관한 보고서 를 인쇄하시 오. 

3. 그라프보기 를 선택하시 오. 

이 실례 에서 사용자는 1, 2, 3을 입 력하여 대 응하는 명 령 들을 호출한다. 

현재 는 단순한 문장렬 을 현시하지 않고 HCI 는 도형 방식 을 리용한다. 원도우, 아이 콘， 
내리 펼침 차림표 me « w ) 들은 도형 사용자대면부 ( GUI ) 의 요소들이다. 원도우즈체계 
의 과잉으로 인하여 X window 와 같은 표준체계가 개발되였다. 또한《지적과 찰칵 ( po 泊/ 
and c // c 句》과 같은 선택 이 표준방식으로 되고 있다. 사용자들은 마우스를 움직 여 화면우 
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의 카소르를 희망하는 응답 (>«•«/’’) 에로 움직이며 마우스단추를 눌러 (" c & r ) 그 응답을 
선택 한다. 

그러나 목적하는 프로그람제품이 현대적인 기술을 리용할 때에도 설계자들은 그 제 
품을 인간이 리용하게 된다는것을 잊어서는 안된다. 달리 말하면 HCI 설계자들은 문자의 
크기, 대문자사용, 색, 행길이, 화면의 행수와 같은 인간적인자들을 고려하여야 한다. 

앞에서 설명한 차림표는 인간적인자가 적용되는 또 한가지 실례이다. 만일 사용자가 
《3. 그라프보기 를 선택하시 오.》를 선택하면 다른 선택 목록을 제 시하는 차림 표가 나타 
난다. 차림 표구동체 계 를 주의 깊게 설계하지 않으면 상대 적 으로 단순한 조작을 실 현하기 
위하여 사용자가 긴 차림 표렬을 다루어 야 할 위 험성 이 생기 게 된다. 이와 같은 지 연현상 
冬 사용자를 노엽히 며 때 로는 그것 이 부적 당한 차림 표를 선택하게 할수도 있 다. 또한 
HCI 는 사용자가 제 일 웃준위차림 표에 로 되 돌아 가지 않고 앞서 진행한 선택 을 변화시켜 
다시 시작할수 있도록 설계하여야 한다. 이러한 문제는 GUI 가 리용될 때에도 존재할수 
있다. 왜냐하면 많은 도형사용자대면부들은 본질상 매력적인 화면형식으로 현시되는 차 
림 표렬 이 기 때 문이 다. 

때때로 단일한 사용자대면부가 모든 사용자들을 만족시킬수도 있다. 실례로 만일 어 
떤 쏘프트웨어제품을 콤퓨터전문가와 콤퓨터 에 대 한 경험 이 없는 중학교중퇴생 이 리용하 
기로 되여 있다면 두개의 서로 다른 HCI 모임을 설계하는것 이 좋다. 이 두가지 대면부는 
예정된 사용자들의 숙련수준과 심 리 학적측면에 맞추어 만들어 진다. 이와 같은 기 술은 
여러가지 수준의 정교성을 요구하는 사용자대면부들을 병합함으로써 확장될수 있다. 만 
일 제품이 사용자가 자주 실수하거 나 방조수단들을 련속적 으로 쏘프트웨 어호출하는것 으 
로 인하여 보다 정교성이 낮은 사용자대면부에 만족스러워 할것이라는 론리에 기초하여 
만들어 진다면 사용자에게는 응당 자기의 숙련수준에 보다 적합한 화면이 보여 지게 된 
다. 그러 나 사용자가 제품에 보다 정통하게 되면 보다 적은 정보를 제공하여 주는 간소 
화된 화면이 현시되게 되며 보다 빨리 목적을 달성할수 있게 한다. 이러한 자동화된 방 
법은 사용자의 실패를 줄이고 생산성을 증가시킨다 [Schach and Wood , 1986]. 

HCI 를 설 계하는 과정 에 인 간적 인 자들을 고려하면 학습시 간의 감소와 오유률의 저 
하를 비롯한 많은 리익을 얻을수 있다. 비록 방조(뇨切)수단들은 언제나 제공되여야 하 
지만 그것들은 정교하게 설계된 HCI 보다 덜 활용된다. 이것 역시 제품의 생산성을 증 
가시킨다. 어 떤 제 품 또는 제 품그룹전환에서 HCI 현시의 단일성 을 보장하는것 은 사용 
자로 하여 금 이 전에 본적 이 없는 화면들을 리용하는 방법 을 직 관적 으로 알수 있게 한 
다. 왜 냐하면 그러한 화면들은 그들이 이 미 정 통하고 있는 화면과 류사하기때 문이 다. 
마킨토쉬 쏘프트웨 어설계 자들은 이 와 같은 원리 를 고려하여 제 품을 만들고 있다. 이 것 
이 바로 마킨토시용프로그람이 그처럼 사용자에게 친숙하게 하는 원인들중의 하나이다. 
사용자에 게 친절 한 HCI 를 설계하는것 이 필 요하다는것 은 하나의 단순한 상식 으로 되 였 
다. 이것이 사실인가 아닌가에 관계없이 매 제품에 대한 HCI 신속원형이 작성된다는것 
이 본질적 이다. 예정된 프로그람사용자들은 HCI 신속원형을 실험 하고 설계 자에게 목적 
하는 제 품이 실지 로 사용자에 게 친절한가 아닌가 즉 설 계 자들이 필수적 인 인간적 인자 
들을 고려하였는가를 알려 줄수 있 다. 

다음 두개의 절에서 표면상 매력이 있지만 위험을 동반하고 있는 기타 신속원형작성 
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자가 명세서에 수표하면 신속원형작성모형은 
•되여 다음 개발공정에서 리용된다.). 두번째 
의 중요부분으로 리용하여 명세서를 필요 험 
속원형작성모형 은 그림 W -2 에 서 보여 주었 
여 준다. 이 방법 에 서 는 서 면 명 세 서 를 작성 * 
는과 같은 명 세작성 과 관련된 난점 들이 발생 
구성하기때문에 여기서 해야 할 일은 제품。 
3을 서술하고 파일갱신, 암호화, 오유조종과 
|•을 렬 거하는것 이 다. 









한 책임수행여부에 관한 문제에서 의견이 불일치한다면 신속원형을 개발자와 의뢰자사이 
의 계약서의 합법적인 설명으로 취할수는 없을것 갈다. 이러한 리유로 하여 신속원형을 
유일한 명세서로서 리용하지 말아야 한다. 프로그람이 내부적으로 개발되는 경우(즉 의 
뢰자와 개발자가 갈은 기업체의 성원인 경우)에도 사정은 마찬가지이다. 비록 은행의 투 
자관리부의 책 임자가 자료처 리부를 법에 고소할것 같지는 않다고 하여도 의뢰자와 개발 
자사이의 의견불일치는 기관내에서도 쉽게 발생할수 있다. 그렇기때문에 이러한 현상을 
막기 위 하여 쏘프트웨 어 개 발자들은 신속원형 을 쏘프트웨 어 를 내 부적 으로 개 발하는 경 우 
라 하여도 명세서로서 리용하지 말아야 한다. 

신속원형을 서면명세서로서 대치하지 말아야 할 두번째 리유는 유지정비와 관련한 
잠재적인 문제때문이다. 제16장에서 서술된바와 같이 유지정비는 모든 문서작성 이 유효 
하고 갱 신되 는 경 우에 조차 헐치 않은 일 이 다. 만일 아무런 명세서 도 없다면 유지정 비 를 
진행하는것은 전혀 불가능하게 된다. 이 문제 는 요구를 변경시 켜 야 하는 보다 강한 조건 
에서 특별히 심각하게 된다. 서면명세서 가 없으면 유지정 비림에게 현재의 명세서 에 대 한 
명 확한 진술이 주어 지지 않기때 문에 새 로운 명세서를 반영하는 설계문서들을 변경시키 
는 일이 매우 어려워 진다. 

이 와 갈은 두가지 원인으로 하여 신속원형 은 단순히 요구분석기 법 즉 의뢰 자의 실제 
요구가 정 확히 도출되 였 다는것 은 확인하기 위한 한가지 수단으로서 리용하여 야 한다. 그 
다음 서면명세서들은 신속원형을 토대로 하여 만들어야 한다. 

1 0. 6. 신속원형의 재리용 

앞에 서 고찰한 두가지 신속원형 작성 모형 에 서 신속원형 은 요즈음에 는 쏘프트웨 어 개 발 
과정에서 리용되지 않는다. 그리 좋지는 못하지만 한가지 다른 처리방법은 신속원형을 
제 품으로 완성 될 때 까지 발전시키 고 세 련시 키 는것 이 다. 이 과정 은 그림 10-3 에 보여 주 
었 다. 리 론적 으로 이 방법 은 쏘프트웨어 를 빨리 개 발하는데 로 이 끌어 간다. 결 국 신속원 
형을 구성 하고 있는 코드들을 버리는것 대신에 거기 에 지식을 추가시켜 나가면서 신속원 
형을 최종적인 제품으로 전환시킨다. 그러나 실천적으로 이 과정은 그림 3-1 에서 보여 
준 구성 및 수정(6«아-패必刀功방법과 매우 류사하다. 구성 및 수정모형 에서와 마찬가지로 
이 러한 형식의 신속원형작성모형 에서 제기되는 첫번째 문제는 신속원형을 세 련시키는 과 
정에서 작업하고 있는 제품들에 대하여 변경을 가해야 한다는것이다. 이것은 그림 1-5 에 
서 보여 준바와 같이 품이 많이 드는 처 리 방법이 다. 두번째문제 는 신속원형 을 작성할 때 
1차적인 목적은 작성속도라는것이다. 신속원형은 주의 깊게 전문화되고 설계되며 실현되 
는것 이 아니 라 조급하게 결 합되 는것 이 다. 명세서 와 설계문서 가 없으면 결과적 인 코드는 
유지정비 하기가 어렵 고 품이 많이 든다. 하나의 신속원형을 작성한 다음 그것을 버리고 
제품을 처 음부터 다시 설계하는것은 비 경제 적인것 갈지 만 그것 은 단기 적관점 에서 나 장기 
적관점 에서 모두 신속원형 을 품질 좋은 쏘프트웨어제품으로 전환시키 려고 하는것 보다는 
훨씬 값이 눅다 [ Brooks , 1975]. 
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그림 10-3. 신속원형작성모형의 그릇된 판본 

신속원형을 버려야 할 또 하나의 리유는 제품의 성능 특히는 실시간체계에 관한 문 
제 때문이 다. 시 간계 약이 만족된다는것 을 담보하기 위 하여 서 는 제 품을 신중하게 설 계하여 
야 한다. 이 와는 대 비 적으로 신속원형 은 의뢰 자에 게 중요한 기능성을 현시하도록 구성된 
다. 즉 이때 성능에 대 하여서는 론의하지 않는다. 결국 만일 신속원형 을 정 식제품으로 세 
련시키려고 하면 응답시간 및 기타 시간적제약이 만족되지 않을수 있다. 

신속원형 이 버 려 지 고 제 품이 정 확하게 설계 되 고 실현되 였 다는것 을 확인하기 위 한 
한가지 방법 은 신속원형 을 제 품과는 다른 언어 로 작성하는것 이 다. 실례 로 의 뢰 자는 제 품 
이 Java 언어 로 작성 되 여 야 한다고 규정할수도 있 다. 만일 신속원형 을 HTML 로 실현된다면 
그것은 버려야 한다. 먼저 신속원형이 HTML 로 실현하고 목적 하는 프로그람이 해야 할 모 
든 사항 또는 대부분의 사항들에 의뢰 자가 만족할 때까지 그것을 세 련시 킨다. 다음으로 신 
속원형을 구성할 때 획득한 지식과 숙련에 기초하여 제품을 설계한다. 마지막으로 설계를 
Java 언 어 로 실 현 하고 시 험 을 마친 제 품을 의 뢰 자에 게 일 반적 인 방식 으로 넘 겨 준다. 

그러나 신속원형 또는 특수하게 신속원형의 부분들을 세련시키는것이 허용되는 한가 
지 실례가 있다. 즉 신속원형의 부분들이 콤퓨터에 의하여 생성된다면 이러한 부분들은 
최종제 품으로 리용될수 있다. 실례 로 사용자대 면부는 신속원형 의 중요한 응용국면으로 
된다 (10.3). 

화면생 성프로그람，보고서생 성프로그람 (5.4) 과 같은 CASE 도구들이 사용자대 면부를 
생성하는데 활용될 때 이와 갈은 신속원형의 부분들은 실지로 생산성과 품질이 좋은 
쏘프트웨어 의 부분으로서 리용될 수 있 다. 

신속원형을《랑비》하지 않으려는 욕망은 결국 일부 단계들에서 리용하고 있는 변 
화된 류형 의 신속원형작성모형 이 생겨 나게 했 다. 이 모형 에 서 관리 자측은 신속원형 이 
만들어 지 기전에 그 부분들이 다른 쏘프트웨어요소들과 같은 품질보증검사를 거 친다는 
조건하에서 최종제품에 리용될수 있다는것을 결정 한다. 그러므로 신속원형이 완성된후에 
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개발자들이 계속 리용하려고 하는 부분들은 설계 및 코드시험을 거쳐야 한다. 이 방법은 
신속원형작성법을 초월한다. 실례로 설계 및 코드시험을 거친 충분히 질이 좋은 요소들 
은 신속원형에서는 찾아 볼수 없다. 더우기 설계문서들은 고전적인 신속원형의 부분으로 
되지 않는다. 그러나 이와 갈은 혼성방법은 신속원형작성에 투자한 시간과 자금을 회복 
하려고 하는 일부 개발기 업체들의 주목을 끌고 있다. 그러나 코드의 질이 충분히 좋다는 
것을 담보하기 위하여서는 그러한 신속원형은 어쨌든 습관된 《조기》원형에서보다는 천 
천히 구성되지 않으면 안된다. 

다음으로 신속원형에 대한 관리자측의 영향에 대하여 고찰한다. 

10.7. 신속원형에서의 관리문제 

신속원형작성에서 나서는 한가지 난점은 어떤 신속원형에 대한 변경에서의 용이성이 
의뢰자로 하여금 기능적질이 높은 정식제품판본에 대한 모든 중요한 변경을 요구하도록 
부추길수 있다는것이다. 더우기 의뢰자는 제품에 대한 변경을 신속원형에 대한 변경처럼 
빨리 실현할수 있게 되기를 바랄수도 있다. 이와 관련되여 제기되는 또 한가지 난점은 
비록 신속원형이 필요한 모든것을 할수 있을것 같다 하여도 신속원형이 조작상품질은 나 
른데 의뢰자는 조작상 품질이 좋은 제품판본을 기대하고 있다는것을 의뢰자에게 설명하 
여 주는것이다. 신속원형이 리용되기전에 제품개발에 책임 있는 경영자들이 이러한 문제 
들과 련관된 문제들을 의뢰자와 토론하는것이 아주 중요하다. 

모든 새 기술을 도입할 때와 마찬가지로 어떤 개발기업체에서 신속원형작성모형을 
도입하기전에 관리자측이 신속원형작성의 우점과 결함을 알아 차리는것이 사활적인 문제 
로 나선다. 공정하게 말한다면 비록 신속원형작성법에 관한 실례가 강력하다고 하여도 
그것은 물론 아직까지 증명되지 않았다. 실례로 자주 인용되는 한가지 실험은 Boehm , 
Gray , Seewaldt 가 진행한 실험 인데 그들은 하나의 제 품에 대 한 7개의 각이한 판본들을 비 
교하였다 [ Boehm , Gray , Seewaldt , 1984]. 그중 4개의 판본은 명세서를 작성하였고 3개의 
판본은 명세서의 역할을 수행 하는 신속원형으로서 원형화되였다. 실험결과는 신속원형 작 
성법과 명세작성법이 거의 갈은 성능을 가진 제품들을 주었지만 원형화된 제품이 대략 
40% 더 적은 원천코드와 45% 더 적은 노력으로써 개발되였다. 그 원인은 명세작성림이 
아무런 꺼 리낌도 없이 명세서안에 경 고문들을 첨부하였기때 문이 다. 다른 한편 신속원형 
작성 자들은 매 개 특성 을 신속원형안에 서 실 현하여 야 한다는것 을 리해하였 기때 문에 별수 
없 이 본질적 이 아닌 모든 기 능들을 병 합하였 다. 평 균 40% 적 은 원천코드로 하여 원형작 
성판본이 기 능성 과 로바스트성 이 약간 낮다고 평 가되 는것 은 놀라울것 이 없 다. 그러 나 원 
형작성판본이 리용 및 학습의 용이성 에서 보다 좋다고 평 가되는것은 아주 흥미 있다. 결 
국 명세작성 법 이 응집 도가 보 다 좋은 설계 와 통합하기 쉬 운 쏘프트웨어 를 생 성하였 다. 
이 실험 에서 한가지 중요한것은 이 실험 을 7개의 연구생림 즉 2명 으로 구성된 3개의 림 
과 3명으로 구성된 4개의 림이 진행하였다는것이다. 이 프로젝트는 10주동안 진행되였으 
며 제품에 대한 유지정비는 진행되지 않았다. 즉 이 실험은 참가자수，림규모, 프로젝트 
규모, 쏘프트웨 어개 발과정 의 견지 에 서 볼 때 실지제 품에 관한 전형 으로서 볼수 없 다. 그 
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러 므로 Boehm 의 결과를 신속원형 에 대 한 하나의 보증서 처 럼 리 용하는것 은 현명 하지 못 
하다. 오히려 이 실험결과를 신속원형작성법의 약점과 우점을 명세작성법과 비교할 때의 
지 침으로 삼아야 한다. 우에서 언급한 약점외 에도 Boehm 과 그의 동업 자들은 원형작성 법 
으로 만든 제 품이 명세작성 법 으로 만# 제 품보다 통합하기 어 렵 다는것 을 밝혀 냈다. 통 
합의 용이성 은 대규모쏘프트웨어제품 특히 C 4 I ( 명 령，조종，통신, 콤퓨터, 지 능)쏘프트웨 어 
에서 중요한 문제이다. 바로 이러한 리유로 하여 신속원형을 명세작성대신에 리용한 그 
림 m -2 의 모형 을 리용하지 않고 그것 을 요구분석 기 법 으로 리 용하는 그림 m -1 의 신속원 
형작성모형 을 리용한다. 

관리 자는 신속원형 에 대한 이 두가지 측면을 반드시 고려하여 야 한다. 10.5 에서는 신 
속원형을 최종제품으로 전환하는것이 짧은 생각이라는것을 지적하고 있다. 즉 신속원형 
은 오직 의 뢰 자의 요구를 정 확하게 결 정 하기 위한 수단으로서 만 리 용되 여 야 한다. 또한 
일부 경우에 신속원형작성으로 명세작성단계를 대치하고 있다는것이다. 그러나 이것은 
결코 설계 단계를 대 치할수 없다. 개발림은 신속원형 으로부터 엄은 정보와 경험을 훌륭한 
설계 를 만들기 위한 지 침으로 삼을수 있다. 그러 나 신속원형은 급히 만들어 지기때 문에 
훌륭한 신속원형이 훌륭한 설계를 주지 못할수도 있다. 

또 한가지 보다 기 초적 인 론점 은 신속원형작성모형 의 유지 정 비 는 폭포모형만 운영하 
는데 습관된 관리자들에 대하여서는 사고방식을 크게 변화시킬것을 필요로 한다는것 이 다. 
폭포모형 이 기초하고 있는 개념은 첫번에 정확하게 해 야 할것을 수행하는것 이 다. 틀림없 
이 폭포모형 은 개발림 이 이 목적 을 달성하지 못한다면(이 목적 은 좀처 럼 달성할수 없 다.) 
수많은 반결 합고리 들을 결 합하게 된 다. 그러 나 폭포모형개발림 에 서 리 상적 인 점 은 개 발 
공정의 매 단계를 오직 한번만 수행한다는것 이 다. 이와는 반대로 신속원형 은 자주 변경 
되고 그다음 버려 지도록 만들어 진다. 이러한 개념은 관리자들이 일반적으로 습관되여 
있는 방법 과 정 반대 이 다. 신속원형방법 이 여 러 차례 반복하면서 목적 을 달성하는것 은 한 
번의 실행으로 목적을 달성하는 폭포모형보다 더 형식적일수 있으며 이러한 론리는 관리 
자가 신속원형작성모형 에 로 전환하도록 납득시키 는데 도움이 될 수 있 다. 

관리 자의 관점 에서 다른 방법 을 필요로 하는 신속원형작성모형 의 또 하나의 측면은 
의 뢰 자와 개 발자，특히 신속원형작성 림 사이 의 호상작용이 중시 된 다는것 이 다. 폭포모형 에 
서 의뢰 자와 개 발자들사이의 호상작용은 개발림과 의뢰 자 그리 고 의뢰 자와 종업 원들사이 
의 면담들에 의하여 제 약된다. 신속원형작성 법 이 리용될 때 에는 신속원형작성 림과 의뢰 
자림은 신속원형이 수용될 때까지 거의 련속적으로 호상작용한다. 

10.8. 신속원형의 실험 

고돈 ( Gordon ) 과 비 에 만 ( Bieman ) 은 신속원 형 을 리 용하고 있 는 39건의 공개 및 비 공개 
실례연구들을 분석하였 다 [Gordon and Bieman , 1995]. 이 가운데 서 33건은 성 공으로 인정 
되 고 3건은 실패, 3건은 평 가되지 않았다. Gordon 과 Bieman 은 성 공하지 못한 실례연구들 
은 거의 공개되지 않았다는것을 지적하였다. 결론적 으로 그들은 자기 들이 진행한 분석 이 
신속원형작성 으로 인한 높은 성 공률을 반영 하고 있 다고 주장하지 못하였 다. 오히 려 그들 
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의 론문은 신속원형 이 성 공적 으로 리 용된 여 러 가지 성 공적 쏘프트웨 어프로젝트들에 대 한 
보고서로 된다. 

공개된바와 같이 실례연구들은 매개의 흥미 있는 론점들을 전혀 반영하지 못하고 
있다. 실례로 사용의 용이성에 관한 론평은 오직 17건의 실례연구에서만 제시되였다. 
신속원형작성 으로 인한 정 식제품의 사용용이성 에서의 개 선은 이 17건의 실례모두에서 
보고되 고 있다. 기 타 22건의 실례연구들 은 제품 을 사용하기 어 렵 다는것을 주장하지 
못하고 있 다. 그러 므로 비 록 자료가 불완전하고 전문적 인 화제 들이 명 백하게 언급되 지 
않았다고 하여도 일 련의 결론을 내릴수 있다. 

사용자관여 에 대 하여 론평 한 모든 실례연구들은 열성 적 인 관계 자들은 이 미 개 발공정 
에 참가하고 있다는것을 보고하고 있다. 또한 신속원형들은 의뢰자의 요구를 만족시킨다 
는것 이 밝혀 졌다. 기 타 론쟁에서 는 또 다른 견해 들도 있다. 실례 로 4건의 연구들은 신속 
원형이 제품들이 보다 적게 배포되게 하였다고 보고하고 있으며 한건은 원천코드규모가 
증대 되 였 다는것 을 보고하고 있 다. 많은 실 례연구들에 서 신속원형작성 에 서 몇 가지 불필요 
한 특성들이 실현되였다는것을 언급하고 있지만 두건은 이와 갈은 특성들이 증가하였다 
는것을 보고하고 있다. 

언어선택은 신속원형작성 에서 더 욱 중요한 문제 로 제 기 된다. 39건의 실례연구에서 
총 26개 의 각이한 언어들이 리용되 였 다. 가장 많이 쓰인 언어 는 Lisp (4 건)와 Smalltalk (3 
건)였 다. 

결과들에서 가장 중점으로 된것은 신속원형을 버려야 하는가에 관한 문제이다. 수많 
은 쏘프트웨 어개 발과정 들이 리용되 였기때 문에 이 론쟁 에 대 하여 명 확한 결론을 짓기는 
어렵다. 일부 실례들에서 신속원형은 통채로 최종제품으로 전환될 때까지 성과적으로 완 
성되 였다. 또 다른 실례들에서는 신속원형의 일부만이 보류되고 나머지는 버리였다. 하 
나의 실례 에서 설계 단계 가 신속원형의 반복을 요구하였다. 일부 실례연구들에서는 관리 
자측이 사전에 신속원형 이 보류되고 완성될것 이 라는것을 규정하였다. 실례연구중에서 22 
건은 신속원형전체 혹은 부분을 보류완성해 야 한다는것을 특별히 권고하고 있으며 8건은 
신속원형 을 버 린 다는것 을 주장하였 다. 

신속원형을 보류하는것은 규모가 큰 쏘프트웨어제품에서 특별히 중요하다는것이 밝 
혀 졌 다. 39건의 실례연구에서 7건은 규모가 방대한데 (10 만행 이상의 코드 ) 7건모두가 신 
속원형전체 또는 부분을 보류하고 있다. 모든 제품들에서 신속원형을 버려야 한다고 믿 
는것이 일반적인 견해이다. 이후 이 분야에 대하여 연구할 필요가 있다. 특히 10.5 에서 서 
술된 변형된 신속원형작성 모형 을 리 용하여 야 하는가를 아는것 이 중요하다. 즉 신속원형 이 
작성되기전에 원형의 부분들이 최종제품에서 활용될수 있는가 그리고 개발자가 보류하려 
고 하는 부분들이 설계와 코드검토를 거처야 하는가를 관리자측에서 결정하여야 한다. 

이러한 연구로부터 일련의 림시적인 결론을 내릴수 있다. 

첫째로, 신속원형작성이 성공적인 쏘프트웨어개발에로 이끌어 갈수 있는 실행가능한 
기법이라는것이다. 동시에 수많은 위험가능성도 있다. 만일 신속원형이 보류되면 결과적 
인 제품이 잘못 설계되여 유지정비가 어렵게 되고 불완전하게 수행될 위험성이 있다. 이 
러한 위험성은 아마도 제품의 규모에 비례하여 커지는것 같다. 그러나 이러한 위험성은 
감소시킬수도 있다. 
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그 한가지 방법 은 10.5 에 서 서 술한 변형 된 신속원형 을 리용하는것 이 다. 실 례연구에 
서의 보고와 의도적으로 조종한 실험사이에는 차이가 있다. 그러나 쏘프트웨 어공학에서 
조종실험 은 매 우 어 려우며 한가지 다른 방법은 다른 사람들의 경험 을 배우는것 이 라는것 
을 명심해야 한다. 

10.9. 요구사항도출 및 분석들 위한 기법 

1차적 인 요구사항도출기 법은 면담을 진행하는것 이 다 (10 丄 1). 이 것을 례증하기 위하여 
요구분석림이 프로젝트의 첫 시작에서 하나의 신속원형 을 작성한다고 가정하자. 그러나 
신속원형의 첫 반복이 작성되기전에 개발림과 관련된 의뢰자와의 면담이 철저히 진행되 
면 될수록 첫 반복이 의뢰자의 요구를 정확하게 반영할 가능성은 더 커진다. 다른 한편 
신속원형을 단순히 모아 놓으면 긴 세련과정을 수행해나가는데서 시간이 적게 걸리거나 
비용도 효과적 이 다. 왜 냐하면 명백히 신속원형작성은 요구분석기 법 이지 요구도출기 법 이 
아니기 때문이다. 

만일 종 (/ bm ) 기 법 이 리용된 다면 또한 면 담을 진행하는것 이 필요하다 (10 丄 3). 폼, 보 
고서，일감서술을 주의 깊게 음미해 보는것은 매우 중요하다. 그러나 이러한 고찰로부터 
하나하나 수집한 정 보의 정 확성 을 확인 하기 위한 유일한 방도는 련관된 의 뢰 자측 성 원들 
과 면담하는것이다. 결국 이 절의 시작에서 주장한바와 같이 면담은 사실상 1차적인 요 
구도출기 법 이 다. 한편 m .2 에 서 지 적 된바와 같이 신속원형작성 은 가장 정 확한 요구분석기 
법 이 다. 신속원형작성 은 제 품의 작업 모형 을 구성할수 있게 하여 기 타 기 법 들보다 의뢰 자 
의 실지 요구를 더 잘 만족시키 는것 갈다. 신속원형 을 리용하지 않으면 요구분석단계 가 
부적 당하게 수행 되 며 의 뢰 자의 요구가 목적한 제 품을 완전히 만족시키 지 못할 중대한 위 
험 성 이 발생한다. 


10. 10. 요구사항확정단계에서의 시험 

비록 요구사항확정단계의 목적이 의뢰자의 실지요구를 확정 하는것이라고 하여도 일 
반적으로 의뢰 자는 목적하는 제품의 1차사용자로는 되지 않는다. 그렇기때 문에 사용자에 
게 신속원형을 실험 하며 의뢰 자가 찬성 하는 경우에 쏘프트웨 어제품의 배포판에서 실현될 
변경을 제기할 기회를 주는것이 매우 중요하다. 

그렇 기때 문에 신속원형작성단계 에서 쏘프트웨 어품질보증그룹의 임무는 의뢰기 업체의 
련관된 개별적사람들이 신속원형과 작용하는 기회를 가지며 그들의 제의가 의뢰자 또는 
사용자의 제의를 분석할 책임이 있는 의뢰자측에 정확히 전달된다는것을 확인하는것이다. 

m .2 에서 언급된바와 같이 앞으로 수행할 단계 에서의 시 험견지 로부터 요구사항확정 
은 본질적 으로 추적 가능해 야 한다. 이 것을 위하여 요구문들에 번호를 달아 SQA 가 이 후 
단계들에서 그것들을 추적할수 있게 하는것 이 필요하다. 번호달기는 요구서의 매 항목들 
을 실현하는 명령묶음들이 린접하여 있는 주석의 형식으로서 신속원형에 표현되여야 한 
다. 
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10. 11. 요구사항확정단계를 우 I 한 CASE 도구 

해석형언어듈은 일반적으로 신속원형작성을 위한 훌륭한 매체로서 복무한다. 해석형 
언어들이 콤파일되거나 링크될 필요가 없기때문에 신속원형의 개발을 보다 빠르게 한다. 
또한 의뢰자가 제기하는 작은 변경요구도 신속원형이 현시되는 기간에 자주 실현될수 있 
다. 해석형언어 들은 일반적으로 를파일형언어 보다도 실행에서 덜 효과적이며 유지정비에 
서 제기되는 난점들도 일부 해석형언어들과 관련되여 있다. 그러나 신속원형내에서는 이 
러한 론쟁이 아무런 관계도 없다. 요점은 신속원형을 빨리 종합하고 그다음 버리는것인 
메 대부분의 해석형 언어들은 이 목적을 실 현 하는데서 리상적 이 다. 신속원형 작성 언어와 
련관되여 있는 CASE 도구들을 리용하면 더 좋은 효과들을 얻을수 있다. 실례로 Smalltalk 
는 여 러 가지 수단으로서 사용자를 돕고 신속원형작성 과정 을 촉진하는 환경 을 가지 고 있 
다. Interlisp 환경은 Lisp 프로그람작성자들을 지원하는 이와 류사한 제품이다. Java 는 이식 
성 이 좋은 해석형 언어이 다. 많은 Java 개 발환경들이 현재 보급되고 있는데 앞으로 더욱 기 
대가 클것으로 보인다. 앞에서 언급한것처럼 Perl 은 신속원형을 작성하기 위한 보편적 인 
프로그람작성언어 이 다. HTML 은 광범히 리용되 고 있는 또 한가지 신속원형작성언어 이 다. 
만일 신속원형을 버려야 한다면 (10.7 에서 서술된바와 같이) HTML 은 보다 좋은 우월성을 
나타낸다. 배포제품을 HTML 로 작성한다는것은 거의 생각조차 할수 없는 일이므로 
HTML 의 리용은 사실상 신속원형 이 버 려 질것 이라는것 을 담보하고 있다. 

최 근년간에 Oracle, PowerBuilder, E«2 와 같은 4 세 대 언어들이 신속원형 작성 에 리 용되 
였다 (4GL 寒 14.2 에서 론의된다). 여기 에는 여 러 가지 원인이 있다. 첫째 로 4 세 대언어의 설 
계 목적 이 보다 적 은 명 령 들로서 Java, Ada, C++ 와 같은 3 세 대언어 들과 같은 기 능을 달성 
하는것 이 다. 결 국 신속원형 은 4GL 을 리용할 때 아마도 더 빨리 배 포될 것 이 다. 둘째 로 대 
다수 4GL 들은 해석형 이 다. 이것은 이 절의 서두에서 서술한것 처 럼 신속원형작성 을 촉진 
시 킨다. 셋째 로 대 다수 4GL 은 강력한 CASE 도구들로 지 원된 다. 결국 신속원형작성 과정 을 
더욱 촉진시 킨다. 

다른 한편 신속원형작성 에 서 4GL 의 리용은 고유한 결 함을 가질 수 있 다. 4GL 이 매 장 
된 CASE 환경 은 자주 완전 한 쏘프트웨 어개 발공정 에 리 용될 보다 큰 도구모임 의 일 부분으 
로 된다. 4GL 공급자가 일 반적 으로 권고하는 쏘프트웨 어개 발공정 은 신속원형 을 작성 하고 
그다음 그것 을 최 종적 인 제 품으로 될 때 까지 성 과적 으로 세 련시키 는것 이 다. 결 국 공급자 
는 흔히 쏘프트웨 어개 발공정 이 구성 및 수정모형 으로 퇴 보하는가에 관심 을 돌리 지 않는 
다. 공교롭게 도 대 다수 4GL 공급자들의 유일 한 목적 은 개발림 에 서 자기 들의 단일 한 제 품 
즉 어 떤 프로젝 트의 모든 국면을 조종할수 있는 단일한 CASE 환경 을 구입 한다는것 을 확 
인 하는것 이 다. 

쏘프트웨 어개 발관 리자가 쏘프트웨 어개 발공정 의 모든 관계 를 지 원 할 어 떤 CASE 환경 
을 구입 하기 위해 수만딸라를 지 출하였 다고 하자. 이 제 신속원형 들이 버 려 질수 있 다는 
것 을 확증하기 위하여 신속원형작성 에 리 용될 다른 언어 로 된 개 발프로그람을 사는데 돈 
을 더 지 불하도록 경 영 자를 납득시키 는것 은 쉬 운 일 이 아니 다. 그것 은 경 영 자가 자기 가 
이 미 새 로운 개 발환경 의 한 부분으로 되 는 아주 좋은 신속원형작성 도구를 구입하였는데 
불필요한 추가적인 신속원형작성수단을 사는데 돈을 들이라고 요구한다고 반박할수 있기때 
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문이 다. 그러 므로 경 영 자에 게 신속원형 작성 을 위 한 추가적 인 수단이 나 작업 대 ( WW 次뇨 « c 幻를 
사는데 드는 비용이 신속원형을 생산품질이 좋은 쏘프트웨어로 전환하고 그다음 그 제품 
을 유지정비하려고 할 때 드는 잠재적인 거대한 비용에 비해 작다는것을 보여 주어야 한다. 

10. 12. 요구사항확정단계에서의 척도 

요구사항확정 단계 의 한가지 중요한 특성 은 요구사항확성 림 이 의 뢰 자의 실제 요구를 
얼마나 빨리 결정 하는가 하는것 이 다. 그러므로 요구사항확정 단계 에서의 한가지 유용한 
척도는 요구휘발성에 대한 측도이다. 요구사항확정단계에서 요구가 얼마나 자주 변경되 
는가를 기 록하는것 은 관리 자측에 게 요구사항확정 림 이 제 품의 실제 적 요구에 대 한 집 중률 
을 결정하기 위한 방법을 제공하여 준다. 이와 갈은 척도는 그것이 면담이나 대본작성과 
같은 임의의 요구도출기법에 적용될수 있다는 우월성을 가지고 있다. 

요구사항확정림이 자기의 과제를 얼마나 잘 수행하고 있는가를 재는 또 한가지 측도 
는 쏘프트웨어개발의 나머지 단계들에서 변경되는 요구의 개수이다. 만일 명세작성, 설계 
그리고 그이후 단계들에서 많은 요구들이 변경되야 한다면 림이 요구사항확정단계를 수 
행하는 방법을 철저히 분석하여야 한다는것은 명백한 사실이다. 이러한 척도는 이 장에 
서 서술되는 모든 요구도출기 법들에 적용할수 있다. 

신속원형이 리용될 때 유용한 한가지 척도는 의뢰자와 사용자가 신속원형을 실험할 
때 매 신속원형특성들이 시도되는 회수이다. 실례로 만일 매 사용자가 차림표에서 화면 
J 를 적 어도 한번 선택 하였으나 화면 B 는 누구도 선택하지 않았다면 개발림은 의뢰자에게 
이 두 화면에 대하여 질문하여야 한다. 특히 개발자들은 화면 J 가 그에 대한 실행시간이 
최소로 되 도록 설계할 정도로 중요한가 또 화면 B 가 제품에 포함될 필요가 있는가에 대 
하여 알아야 한다. 만일 그렇 다면 적 어도 한명의 사용자는 화면 B 를 실험하여 야 한다. 
모든 화면들이 사용자의 요구를 충족시켜야 한다는것은 사활적인 문제이다. 

10 . 13. 객체지향요구가 존재하는가 

이 장에는 객체지향파라다임에 속하는것이 전혀 없다. 이것은 무엇때문인가고 묻는 
것은 응당하다. 이 책의 제목이 객체지향 및 고전쏘프트웨어공학인데 객체지향요구에 관 
한 자료가 없다는것은 심중한 생 략처 럼 생각될수도 있다. 

이에 대한 대답은 《객체지향요구》라는것은 전혀 없으며 또 없어야 한다는것이다. 
요구사항확정단계의 목적은 의뢰자의 요구를 결정하는것이다. 즉 목적하는 체계의 기능 
은 무엇으로 되여야 하는가 하는것이다. 요구사항확정단계에서는 체계가 어떻게 작성되 
여야 하는가에 대하여서는 아무것도 하지 않는다. 고전적사용자안내서 또는 객체지향사 
용자안내 서 를 언급하는것 이 의 미 없는것 과 마찬가지 로 요구사항확정 단계 에서 고전적 파라 
다임 이 나 객체지 향파라다임을 언급하는것 은 의미 가 없다. 사용자안내서 는 쏘프트웨 어 제 
품을 실행할 때 사용자가 수행하여야 할 단계들을 서술하고 있지 제품이 어떻게 만들어 
졌는가에 대하여서는 아무것도 서술하고 있지 않다. 이와 같은 방식으로 요구사항확정단 


323 



계에서는 제품이 무엇을 하기로 되여 있는가를 서술하며 그 제품이 작성되는 방법은 그 
안에 들어 가지 않는다. 

객체지향요구와 같은 말은 없다는것을 범주적으로 서술하면서도 그러나 객체지향파 
라다임이 사실상 요구사항확정단계에 들어 갈수 있는 한가지 방법이 있다는것을 언급하 
지 않을수 없다. 이 장에서 강하게 권고한바와 같이 어떤 특정한 프로젝트에 대한 요구 
사항확정 단계 는 신속원형 작성 을 포함한다고 가정 하자. 이 신속원형 을 위 한 코드작성 의 
결과로서 개발림은 목적하는 쏘프트웨어에서 무엇이 콜라스를 구성할수 있는가에 관한 
생각을 비롯하여 문제령역 에 대 하여 간파하게 될것이다. 즉 신속원형이 C 또는 Lisp 와 
같은 고전적 인 언어 로 작성 되 였 다고 하여 도 개발림 은 구성 될 제 품에 대 한 기 본구성 블로 
크들을 파악하게 될것 이 다. 그러면 다음 단계 즉 객체지향분석 (00 A ) 에서 이 정보들은 
00 A 의 첫단계 에서 클라스들을 추출하는데 도움이 될수 있다 (12.2). 이 와 달리 객체지향 
파라다임 은 요구사항확정단계 에 서 아무런 역 할도 놀지 못한다. 

10. 14. 항공음식전문회사 실례연구: 

요구사항확정단계 

많은 항공려 행 자들은 자기들의 음식 요구를 가지 고 있으며 대 다수의 항공회 사들은 그 
들의 요구를 만족시키는 음식을 공급하려고 노력한다. 실례로 대부분의 항공회사들은 남 
새료리，해산물, 정결한 식료품은 물론 당뇨병환자용음식, 저지방，저콜레스트린，저단백， 
저카로리, 저염식사들을 봉사하는데 충분한 주의를 돌린다. 어린이들의 식사도 아무때나 
주문할수 있다. 일부 항공회 사들은 무유당식사를 공급할것 이 다. 비행기 안내원들에 게는 특 
별식사를 요구하는 승객들의 명 단과 그들의 좌석번호가 제공된다. 그러면 특별식사가 규 
정식사와 같은 시 간에 봉사된다. 

거의 모든 기업결재에서와 마찬가지로 이러한 특별식사를 제공할 때 거래가 진행된 
다. 려객인원수를 증가시키고 려객들에게 친절히 봉사하는데서 리익이 돌아 온다. 결국 
어떤 항공회사가 특별식사봉사를 하지 않게 되면 특별식사봉사를 하는 항공회사보다 승 
객들을 잃게 될것 이 다. 다른 한편 특별식사를 제공하는데 비용이 든다. 

1. 특별식사에 들어 가는 재료들은 규정식사용재료들보다 값이 비쌀수 있다. 

2. 특별 식 사는 상대 적 으로 적 게 봉사되 기 때 문에 대 량구입 에 의한 저 축은 있을수 없 다. 

3. 일 부 항공회 사들은 자기 들의 주방에 서 특별 식 사를 준비한다. 그대 신 그들은 외 부료 
리공급원과 계약을 맺고 특별식사를 공급하는데 이것은 비용을 더욱 증대시킨다. 

4. 매개 특별식사는 중심주방으로부터 비행 이 시 작되는 비 행장까지 수송되 여 야 한 
다. 거래비 및 사무처리비용이 이 과정에 포함된다. 

5. 흔히 특별식사는 예정된 접수자가 소비하지 않게 된다. 실례 로 만일 어떤 려객 
이 마지 막순간에 자기 의 려 행 계 획 을 바꾸 거 나 비 행 기 가 늦게 도착하게 되 면 
식사는 그것을 주문한 원래 비행기에 실려 있게 된다. 

6. 비록 특별식사는 미리 주문되였다고 하여도 사람들의 실수로 하여 때때로 해당 
한 비행기에 정확히 실려 지지 않게 된다. 
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총적으로 대다수 항공회사들은 특별식사를 봉사하는데서 엄는 리득이 비용에 비하여 
훨씬 가치가 있다는것을 알게 되였다. 항공음식전문회사는 자기들이 항공봉사하는 고도 
로 표준화된 음식들을 늘 자랑하여 왔는데 그 경쟁자들은 현재 기껏하여 맛이 없는 작은 
땅콩구럭을 공급하고 있다. 

지금까지 항공음식전문회사의 수익성은 비행기안에서 항공전문식사를 하는데 좀 비 
싼 값을 물어도 무방해 하는 승객들에 대한 안정된 공급에 의하여 담보되여 왔다. 그러 
나 최근에 항공음식전문회사의 수입한계는 축소되였으며 회사관리자측은 경비를 줄일 방 
도를 찾고 있다. 특별식사를 공급하는데 드는 높은 비용은 그것을 주문한 승객에게 극히 
적은 량의 특별식사가 차례진다는 일화와 결합되여 특별식사를 항공음식전문회사의 통계 
원을 비난하는 요인으로 되게 하였다. 

그러 나 그 어떤 조치를 취 하기에 앞서 항공음식전문회사 관리 자측은 특별식사계획의 
성공과 실패에 관련된 믿음직한 자료를 얻으러고 한다. 또한 특별식사는 외부공급원에 
의 하여 공급되 기 때 문에 일 부 항공회 사관리 자측은 항공음식 전문회 사의 주방에 서 품질조종 
으로 인하여 이 식사들이 규정된 항공음식전문회사음식의 높은 기준을 만족시킬수 없지 
않는가고 의 심 한다. 그렇 기 때 문에 승객의 만족성 검 사는 특별식 사의 품질 인식 을 결정 하는 
데로 이어 져야 한다. 또한 항공음식전문회사 관리자측은 특별식사가 비행기에 정확히 
실리지 못한 비률을 알려고 한다. 

특별식사를 봉사하는 기타 대다수의 항공회사들과 마찬가지로 작성된 비행시간 24 h 
전에 항공음식예약체계의 자료기지는 특별식사에 대한 요구를 주사한다. 공급원들이 특 
별식사가 련관된 비행기에 제때에 운반된다는것을 확인할수 있도록 보고서가 작성된다. 
그다음 모든것 이 운반된 직후에 비 행기안내 원을 위한 보고서가 비 행기 에 탑재된 콤퓨터 
에서 인쇄된다. 이 보고서에는 예약식별자, 이름，특별식사를 주문한 비행기에 오른 모든 
승객들의 죄석번호, 식사류형 등이 포함된다(승객들은 비행기에서 식사를 하기전에 어떤 
형 식 으로 자기의 신분을 확인시켜 야 한다. 결국 비 행 기의 콤퓨터 는 이 보고서 를 인쇄하 
는데 필요한 정보를 얻게 된다.). 

특별식 사에 관하여 관리 자측이 요구하는 정 보를 얻 기 위 하여 서 는 항공음식전문회 사 
쏘프트웨어 에 일정한 변경 을 가해 야 한다. 

첫째로, 특별식사가 주문될 때마다 다음과 갈은 정보를 기록하여야 한다. 즉 예약식 
별자，비 행기번호, 날자, 시 간, 승객이름과 주소, 주문한 특별식사류형 을 기록한다. 이 정 
보는 새로 작성한 프로그람이 특별식사자료를 분석하는데 리용될것이다. 둘째로, 비행기 
콤퓨터에서 인쇄되는 특별식사목록은 세로 렬 지은 선택직사각형들을 포함하게 될것이다. 
비행기안내원들은 만일 관심하는 식사가 비행 기 에 실렸다면 해 당한 직사각형 이 그늘지게 
표시 한다. 

비행이 끝난후 이 목록이 검토된다. 만일 해당한 직사각형이 그늘지게 표식되였다면 
그 승객은 비행기에 랐다는것을 말하며 예약식별자를 포함하고 있는 우편엽서가 승객에 
게로 보내지며 그에 게 1부터 5등급까지의 식사를 평 가하도록 요구한다. 

우편엽서 가 되돌아 올 때 그것 을 또 조사하고 후에 보고서 로 작성할 목적 으로 예 약 
식별자와 응답을 기록하여 놓는다. 

결 국 특별 식 사분석프로그람에 는 3개 의 독립 적 인 순차적단계 가 있게 된 다. 즉 출발 
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24 h 전에 만들어 지는 추가기록, 조사목록，조사우편엽서가 있다. 

기 록자료요소들의 형 식은 다음과 갈다[선택마당들은 중괄호안에 넣 었다.]. 

예약식별자 (6 개의 대문자) 

비 행기번호 (3 개의 수자, 오른쪽으로 정돈되며 령 이 채워 진다.) 

비 행날자 (9 개 의 문자: 2개 의 수자로 날자표시，3개 의 대 문자로 달표시 , 4개 의 수자로 
년 표시) 

좌석번호 (3 개의 수자는 오른쪽으로 정돈되며 령 이 채워 진다. 그앞에 하나의 문자가 
있 다) 

승객 이 름 

성 (15 개 문자까지 허용) 

[중간의 첫 문자 (1 개 문자)] 

이름 (15 개 문자까지 허용) 

[뒤불이 (5 개 문자까지 허용)] 

승객 주소 

주소의 첫행 (25 개 문자까지 허 용) 

[주소의 두번째 행 (25 개 문자까지 허용)] 

도시 (14 개 문자까지 허용) 

[주, 구역, 지구 (14 개 문자까지 허용)] 

[우편 대 호 (10 개 문자까지 허 용되 며 수자，_，공백 을 리용)] 

나라 (20 개 문자까지 허용) 

특별식사류형(어린이용, 당뇨병환자용，유태인용, 회교도용，무유당, 저카로리, 저콜레 
스크린，저지 방, 저 단백，저염，해산물，남새료리) 

승객이 비행기에 올랐는가? (1 개 문자) 

특별식사를 실었는가? (1 개 문자) 

식사품질 (1 〜 5) 

새 쏘프트웨어 는 자료기 지 로부터 정 보를 입 력 하고 다음 4가지 보고서가운데 서 사용 
자가 선택 할수 있 게 하여 야 한다. 매 보고서 에 서 그 보고서 의 시 작과 끝 날자는 사용자로 
부터 얻어 져야 한다. 

1. 매 특별식사류형과 특별식사프로그람에 대하여 다음과 같은 내용을 
포함하고 있는 보고서 

특별 식 사가 규정 된 대 로 오른 비률 

특별식사를 주문한 승객이 비행기에 오른 비률 

특별식 사를 주문하였지 만 그 식 사가 오르지 않은 승객 들의 비률 

려객관계부서는 다음과 갈은 보고서를 요구한다. 

2. 보고서작성 기 간내 에 서 특별 식 사가 한번 이 상 오르지 않은 승객 들의 
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이름과 주소 및 이 사건의 발생날자 

3 . 특별식사질 이 최 고급 (5 급)보다 낮다고 생각하는 승객들의 이름과 주소 
및 이 사건의 발생날자 그리 고 식 사류형 

저염식사를 공급하는 외부공급원은 자기 자신의 품질조종프로그람을 가지 고 있어 야 
한다. 그를 돕기 위하여 다음과 같은 보고서 가 또 필요하다. 

4. 봉사한 매 저염식사에 대 하여 비 행 기번호와 날자, 식사의 품질급수 

항공음식전문회사관리 자측은 이 러한 추가적 인 기능을 병 합함으로써 자기들의 현존 
콤퓨터체 계 가 변경될 위험성 에 대 하여 크게 우려한다. 또한 관리 자측은 새 로운 제 품이 
완성될 때까지 내 키지는 않지 만 여 러 가지 검사기들을 구입한다. 따라서 건반으로 구동되 
는 자립형제품이 만들어 져야 할것 같다. 즉 이 제품에서는 예 약방식을 입력하고 승객을 
검 사하며 인쇄 된 특별 식 사를 조사한다(이 것 은 건반입 력 으로 모의 되 게 된다.). 그리 고 우 
편엽서를 조사(이것도 건반입력으로 진행)하고 여러가지 보고서를 만들어 낸다. 때 이른 
제품완성 에 대 처 하기 위한 앞으로의 예 방책 이 현존 콤퓨터체계를 변경시 킬 때 항공음식 
전문회 사관리 자측은 외부쏘프트웨어 기업체를 고용하여 자립형제 품을 만들것을 결정하게 
된 다. 


10. 15. 항공음식전문회사실례 연구: 

신속원형작성 

항공음식 전문회 사관리 자측이 자기 들의 요구를 정 확히 결정 하기 위 하여 직 원들과 심 중 
하게 면담을 하였음에도 불구하고 최종제품이 의뢰자의 실제적요구를 정말 만족시킨다는것 
을 확인하기 위 한 유일 한 방도는 신속원형 을 작성 하는것 이 다. 항공음식 전문회 사쏘프트웨 어 
제품에 리용될 콤퓨터에 적합한 언어들은 C , C ++ 와 Java 이다. 만일 제품이 C ++ 로 실현되 
게 되 면 해 석형 언어인 Java 로 신속원형 을 작성 하는것 이 적 합하다. 그러 나 구성 및 수정 문 
제가 발생하는데도 불구하고 실현림 이 Java 신속원형을 C ++ 로 전환하고 보충적인 기능을 
추가할것 이 라는 위 험성 이 존재한다 (3.1). 다른 한편 만일 제 품이 Java 로 실현된다면 C 도 
C ++ 도 특별 히 좋은 대 용물로는 되 지 않는다. 그 두개 언 어가운데 서 C 가 아마도 더 좋을 
수 있다. 왜냐하면 그렇게 되면 신속원형이 완전히 Java 로 작성되여야 하기때문이다. 만 
일 C ++ 를 리용한다면 실현림은 생산성이 좋은 판본을 처음부터 실현하지 않고 신속원형 
을 Java 로 변환하고 그것을 변경시킬수 있다. 

C 와 Java 신속원형 들은 www . mhhe . com / engs / compsci / schach 에 서 리용할수 있 다. 이 원천 
코드들은 일 반적 으로 명 백하다. 그러 나 3가지 측면은 여 기서 반드시 주의해 야 한다. 

C 신속원형의 한 부분을 그림 10-4 에서 보여 주었다. 그리고 그에 대응하는 Java 신속 
원형부분은 그림 10-5 에서 보여 주었다. 먼저 그림 10-4 또는 그림 10-5 에서 보여 준바 
와 같이 10명까지의 승객레 코드가 하나의 배 렬안에 기 억된다. 정 식제품에서 승객수를 하 
나의 변수로 하는 자료구조가 요구된다. 실례 로 파일 또는 동적자료구조가 리용될수 있 
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다. 그러나 신속원형에서 실현하기 쉽고 빠르기때문에 배럴이 리용되며 신속원형은 몇개 
의 승객레코드로써 검사될수 있다. 류사하게 20개 까지의 비 행기 록이 다른 배 렬에 기 억된 
다. 이것도 그림 10-4 와 그림 m-5 에 반영되여 있다. 

신속원형작성 에 관한 두번째 중요한 측면은 그것 이 미 완성 품이 라는것 이 다. 실례 로 6 
개의 보고서가운데서 저 녁식사에 대 한 보고서와 비 행기에 오른 식사에 대 한 보고서 두개 
만이 실현되였다. 이것은 다른 4 개의 보고서가 이 두개의 보고서와 류사하기때문이다. 이 
4 개의 보고서는 스터브(대용체; stub) 즉 몸체부는 없이 하나의 대면부로 이루어 지는 무 
의 미 부분프로그람으로서 작성 된다. 이 부분프로그람들은 호출될 때 통보문을 현시한다. 
이에 대한 한가지 실례를 그림 10-4 와 그림 m-5 에서 보여 주었다. 이 부분프로그람의 
몸체부를 생략하는것은 신속원형의 기능을 크게 손상시킴이 없이 그 개발을 촉진시킨다. 


#define NUMPASSENGERRECORDS 10 

#define NUMFLIGHTRECORDS 20 

struct passenger_type passenger_records[NUM_PASSENGER_RECORDS]; 

struct flight_record_type flight_records[NUM_FLIGHT_RECORDS]; 

printf ( “ \t\t 24HOUR CATERER LIST\n\n” ); 

printf ( “ \t\t This report is not inplemented in the rapid prototype\n\n\n w ); 

printf ( “ Press <ENTER> to return to the menu” ); 

그림 10-4. 항공음식 전문회 사제 품을 위한 C 신속원형 부분 


public static final int NUM_PASSENGER_RECORDS = 10; 
public static final int NUM_FLIGHT_RECORDS = 20; 


public static CPassenger passengers[] = 

new CPassenger [NUM_PASSENGER_RECORDS]; 
public static CFlightRecord fltRecs[]= 

new CFlightRecord [NUM_FLIGHT_RECORDS]; 


System.out.println ( “ 24 HOUR CATERER LIST \n\n” ); 

System.out.println ( “ This report is not implemented in the rapid prototype\n\n\n w ); 
System.out.println ( “ Press〈ENTER〉to return to the menu "’’); 


그림 10-5. 항공음식 전문회 사제 품을 위한 신속원형 부분 


마지 막으로 신속원형 의 사용자대 면부는 차림 표구동식 으로 작성된다. 이것은 그림 
10-4 와 그림 10-5 의 마지막행에 암시되여 있다. 차림표구동식대면부는 도형사용자대면부 
처럼 세련되여 있지는 않지만 두가지 우점을 가지고 있다. 첫째로，신속원형을 작성할 때 
속도가 빠르다는것 이 다. 강력한 GUI 발생 기 를 리용하지 않는 한 일 반적 으로 단순한 차림 
표구동식 사용자대 면부를 코드작성하는것 이 더 빠르다. 둘째 로， GUI 는 흔히 하드웨 어 와 
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조작체계에 의존한다. 만일 정식제품이 신속원형이 실행되는것과 크게 차이나는 하드웨 
어와 조작체계상에서 실현된다면 GUI 는 처음부터 다시 실현되여야 할수도 있는데 여기 
에는 추가적인 비용과 시간이 소비된다. 이 두가지 원인으로 하여 신속원형은 단순한 본 
문적 사용자대 면부형식 으로 작성하는것 이 더 좋다. 보다 중요한 사용자대 면부를 작성 하기 
위한 결심은 생명주기의 뒤단계들에서 작성될수 있다. 

10 . 16. 요구사항확정단계의 난관 

쏘프트웨 어개 발공정의 다른 매 단계들과 마찬가지 로 요구사항확정 단계 에서도 잠재 
적 인 문제점들과 함정들이 존재 한다. 첫째 로, 목적 하는 제품의 잠재적사용자들과 개 발공 
정의 시작에서부터 성심성의로 협동하는것이 매우 중요하다. 

개별적종업원들은 콤퓨터가 자기들의 일자리를 빼앗게 될가봐 두려워 하면서 콤퓨터 
화를 실현하는데 흔히 압박감을 느낀다. 이른바 콤퓨터시대의 직접적인 또는 간접적인 
결과로써 일어 난 많은 나라들에서의 경제의 불균형적인 성장은 콤퓨터화의 결과로 일자 
리를 잃는 개별적 사람들에 게 미 치 는 부정 적 충격을 보상할 방도가 없 다. 

요구분석림의 모든 성원들은 자기들이 대상하는 의뢰자측 성원들이 목적하는 제품이 
그들의 일자리에 주는 잠재적 인 충격에 대하여 깊이 우려할수 있다는것을 생각해야 한다. 
최악의 경우에 종업원들은 제품이 의뢰자의 요구를 만족시키지 못한다는것을 확인시키고 
이것으로 자기들의 일자리를 보호하기 위하여 일부러 오해하기 쉽거나 틀리는 정보들을 
제공할수도 있다. 그러나 이러한 고의적인 태업은 없다고 하여도 일부 의뢰자측 성원들 
은 단순히 콤퓨터화로 인하여 받는 압박감때문에 잘 협조하지 않을수 있다. 요구사항확 
정단계에서의 또 한가지 난관은 협상가능성이다. 실례로 의뢰자가 원하는것을 등급별로 
규정하는것이 중요하다. 놀랄것 없이 거의 대부분의 의뢰자들은 필요하다고 생각되는 모 
든것을 수행 할수 있는 쏘프트웨 어제품을 가지기를 즐겨 한다. 

이와 같은 제품을 만드는데는 용납할수 없을 정도로 긴 시간이 걸리며 의뢰자가 타당 
하다고 생각하는 비용보다도 훨씬 더 비싼 값이 든다. 그러므로 의뢰자들이 바라는것보다 
적은(때때로 훨씬 더 적은) 요구를 받아 들이도록 의뢰자들을 설득하는것이 필요하다. 

론의하는 매 요구들의 비용과 리 익을 계산하는것 (5.2) 이 이 러한 고려에서 도움을 
줄수 있다. 

또 한가지 실례 의 필요한 협 상기 교는 목적한 제 품의 기 능성 에 관하여 경 영 자들사이 
의 타협에 도달하는 능력이다. 실례로 교활한 경영자는 현재는 다른 경영자의 책임인 어 
떤 업무기능을 자기의 책 임 령 역에 병 합시 킴 으로써만 실현될수 있는 어떤 요구를 포함시 
키는것으로써 자기의 권한을 확장하려고 기도할수도 있다. 놀랄것 없이 다른 경영자는 이 
것을 발견하는 경우 강하게 대항할것이다. 이 경우 요구작성림은 두 경영자를 진정시켜 
론쟁을 해결하여야 한다. 

요구사항확정단계의 세번째 난관은 대 다수 기 업체들에서 요구사항확정림 이 도출하려 
고 하는 정보를 가지고 있는 개별적사람들에게 있어서 깊이 있는 토론을 진행하기 위하 
여 만날 시 간이 모자라는것 이 다. 이 런 경 우가 발생하면 요구사항확정림 은 어 느것 이 더 
중요한가를 결정해야 할 의뢰자에게 개별적사람들의 과제책임이나 구성될 쏘프트웨어제 
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품을 알려 주어야 한다. 그리고 만일 의뢰자가 그 쏘프트웨어제품이 처음 나오는것이라 
고 주장하는데 실패하면 개발자는 거의 실패할 운명에 직면한 프로젝트로부터 물러서는 
것외에 다른 대책이 없을수 있다. 

마지 막으로 유연성과 객체성은 요구도출에서 본질적 인 문제 이 다. 요구사항확정 림성 
원들이 아무런 사전견해가 없이 면담에 림하는것이 사활적인 문제이다. 특히 면담자는 
앞선 면담결과에 기초하여 요구들에 대한 가정을 절대로 하지 말아야 한다. 그러면 이 
가정의 틀안에서 다음면담이 진행되게 된다. 그대신에 앞선 면담에서 하나하나 얻어 낸 
모든 정보들을 의식적으로 덮어 두고 매 면담을 공평한 방법으로 이끌어 나가야 한다. 
요구와 관련하여 너무 이른 가정을 하는것은 위험하다. 작성된 쏘프트웨어를 고려하여 
요구사항확정단계에서 그 어떤 가정을 하는것은 재난을 가져 올수 있다. 


요구사항확정단계의 진행과정 

요구도출 

• 의뢰 자측 성원들과 그들의 요구를 결정 한다. 

요구분석 

• 예비적인 요구문서를 작성한다. 

• 요구문서를 세련시킨다. 

• 목적하는 제품의 중요기능들을 병 합한 신속원형을 작성한다. 

- €속원형을 실험한 의뢰자측 성원들로부터 반결합정보에 따라 신속원형을 병 청한다. 


o 야 

-I-L 一 I 

이 장은 요구사항도출기법의 서술로 시작하며 (10.1) 뒤이어 요구사항분석의 륜곽을 
보여 주는데 (10.2) 그것은 우의 란에 종합되 여 있다. 

신속원형작성에 관한 자세한 정의를 주었다 (10.3). 사용자대면부를 설계할 때 인간적 
인자들을 고려하는것 의 중요성 이 W .4 에 서 론의 되 였 다. 신속원형 을 명세작성 법 으로 리용 
하는 방법은 그리 좋은 방법이 아니라는것을 10.5 에서 보여 준다. 10.6 에서는 신속원형의 
재 리용을 서 술한다. 신속원형작성 에 대 한 관리 자측의 영 향은 10.7 에 서 론의 했 다. 신속원 
형의 시험 이 10.8 에서 론의되 고 요구사항도출을 위한 기 법 들이 10.9 에서 비 교되며 요구사 
항분석 을 위한 기 법 들이 제 시 된다. 그다음 신속원형 을 검 사하기 위한 방법 들 (10 上))，요구 
사항확정단계 를 위한 CASE 도구들 (10. 11)，요구사항확정단계 를 위한 척 도들 (10.12) 이 서 술 
되 였다. 이 장은 객체지향요구사항확정단계 가 존재 하는가에 관한 론의(10.13)，신속원형 
(10.15) 을 비 롯하여 항공음식 전문프로그람에 관한 요구사항확정단계 (10.14), 요구사항확정 
단계의 난관 (10.16) 으로 결속된다. 
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보 충 


요구사항분석 에 대 한 도서 들에 는 문헌 [Gause and Weinberg, 1990; Davis, 1993; and 
Jackson, 1995] 이 있 다. 문헌 [Thayer and Dorfman, 1999] 은 요구사항분석 에 대 한 론문들을 
종합한것이다. 서면원형의 우점은 문헌 [Rettig, 1994] 에서 론의된다. 요구사항확정단계에 
대 한 기 사들은 Communications of the ACM 1995 년 5 월 호와 IEEE Software 1998 년 3 월/ 4 월 
호에 있다. 요구사항분류에 비용 대 리득분석을 리용하는 문제는 문헌 [Karlsson and Ryan, 
199 기에 서술되여 있 다. Ccmmmicatkms of the ACM 199S 년 12 월호에는 요구사항추적과 
관련한 많은 기사들이 포함되여 있다. 

신속원형의 소개와 관련한 도서들은 문헌 [Connell and Shafer, 1989; and Gane, 1989] 
이 다. IEEE Computer 1995 년 2 월호에 는 신속원형 작성 에 대 한 많은 기 사들이 포함되 여 있 
다. 39 개 의 상업 용제 품들에 서 신속원형 작성 의 리 용과 관련 한 보고 [Gordon and Bieman, 
1995] 는 매우 유용한 정보자원으로 된다.문헌 [Lichter, Schneider-Hufschmidt, and 
Zullighoven, 1994] 은 원형 작성 이 중요한 역 할을 수행 하고 있는 5 개 의 산업 쏘프트웨 어 프로 
직 트에 대 하여 자세 히 소개 하고 있 다. 신속원형 작성 모형 은 신속응용개 발 ( ra ; 治/ 쇼 ve / opme 射; 
RAD) 의 한가지 판본으로 된다. RAD 에 대한 여러개의 기사들이 IEEE Software 1995 년 11 
월호에 제시되여 있다. 

인간적인자는 문헌 [Dix, Finlay, Abowd, and Beale, 1993; Browne, 1994, and Preece, 
1994] 에서 론의 되였다. 문헌 [Nielsen, 1993] 은 사용자대면부와의 대화가 어떻게 유용성을 
본질적 으로 개 선할수 있는가에 대 하여 서 술하고 있다. 문헌 [Myers and Rosson, 1992] 에 
서는 총 쏘프트웨 어개 발노력의 절반이상이 제 품의 사용자대 면부와 관련한 부분에 돌려 
질 수 있 다는것 을 지 적하였 다. 

사용자대 면부설계 에 대 한 기 사들은 Communications of the ACMS\ 1993 년 4 월호에서 
찾아 볼수 있다. 문헌 [Gentner and Grudin, 1996] 에서는 사용자대면부설계의 기초를 이루 
는 모형 들을 분석 한다. IEEE Software 1997 년 7,8 월 호에 는 사용자대 면부와 관련 한 많은 
기 사들이 있 는데 특히 문헌 [Sears and Lund, 199 기에 서 이 에 대 하여 론의 하고 있 다. 
Communications of the ACMS\ 1999 년 5 월 호에 있는 론문들의 주제 는 쏘프트웨 어 의 리 용 
문제 이 다. 콤퓨터체 계 에서의 인간적 인자들에 대 한 년차대회 회 보에는 넓 은 측면의 인간 
적인자들에 대한 중요한 정보자원들이 들어 있다. 

문 제 

10.1. 당신이 쏘프트웨어경영자로서 방금 Victoria & Niagara Software 에 접하였다. 
Victoria & Niagara 는 폭포모형 을 성 공적 으로 리 용하면서 소규모기 업 을 위한 체 계 프로그 
탐을 몇년동안 개 발하여 왔다. 경험에 토대하여 당신은 신속원형작성모형 이 쏘프트웨 어 
를 개발하는 아주 우월한 방법이라고 생각한다. 개발기업체가 신속원형작성에로 전환하 
여 야 한다고 당신 이 생 각한 리 유를 설명하는 쏘프트웨 어 개발림 부총재앞으로 보내 는 보 
고서를 작성하시오. 부총재는 한폐지이상 되는 보고서를 좋아 하지 않는다는것을 기억하 
시오. 
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10.2. 당신은 Victoria & Niagara 쏘프트개 발림 부총재 이 다. 문제 10.1 의 보고서 에 
대 답하시 오. 

10.3. 당신이 리용할수 있는 프로그람작성 언어들가운데서 어느것이 신속원형 작성에 
리용되 지 말아야 하는가? 대 답에 대 한 리유를 말하시 오. 

10.4. 신속원형작성 이 개발림 에 크게 도움이 되 지 않을것 갈은 프로젝 트를 서 술하시 오. 

10.5. 10.3 에 서 는 신속원형 작성 이 사용자대 면부를 개 발할 때 특별 히 효과적 이 라는것 을 
설 명하였 다. 이 점 에 관하여 어 떤 환경 에 서 의 뢰 자의 요구를 결 정 하기 위한 등가적 인 
다른 대책이 있는가? 

10.6. 어떤 환경에서 신속원형을 세련시키는것이 리치에 맞는가? 

10.7. 만일 신속원형 이 빨리 구성되지 않으면 어떤 결과가 생기는가? 

10.8. 만일 제 품이 객체지향파라다임 을 리용하여 개 발되 여 야 한다면 신속원형을 리 
용하여야 하는가? 

10.9. (과정안상 목표) 부록 1에 있는 브로드렌즈지역 아동병 원프로젝 트를 위한 
신속원형 을 작성 하시 오. 지 도교원 이 규정한 쏘프트웨어 와 하드웨 어 를 리용하시 오. 

10.10. (실 례연구) 10.4 의 요구로부터 출발하여 Lisp , Smalltalk , 또는 Perl 과 같은 
해석형 언어 로 신속원형 을 작성 하시 오. 

10.11. (실례연구) 항공음식 전문회 사제 품에 관한 신속원형 이 C 로 작성되 였고 
생산품질이 높은 실현은 C ++ 로 작성되게 된다고 하자. C 는 문법적으로 C ++ 의 
부분모임이기때문에 이 신속원형이 제품의 정식판본안으로 완성되여 들어 가는것을 
막으려면 어떻게 하여야 하는가? 

10.12. (실례연구) 항공음식전문회사제품에 관한 신속원형 이 Java 로 작성되 였고 
생산품질이 높은 실현도 Java 로 작성되게 된다고 하자. 신속원형이 제품의 정식판본으로 
완성되여 들어 가는것을 막으려면 어떻게 하여야 하는가? 

10.13. (실례연구) 만일 쏘프트웨어 가 당신에게 도움이 된다면 10.15 의 신속원형 에 
도형 사용자대 면부를 추가하시 오. 

10.14. (실례연구) 10.15 의 신속원형에서 기록배 럴들은 승객과 비행기기록을 
저 장하는데 리 용된다. 이것은 신속원형작성 림 에 있어서 좋은 결정 으로 되 는가? 당신의 
대 답을 안받침하기 위하여 동적자료구조를 리용하여 신속원형 을 기 록하시 오. 

10.15. (실례연구) 10.15 의 많은 신속원형부분프로그람들은 비 여 있다. 실례 로 
특별식사가 한번이상 오르지 않은 매 승객들의 이름과 주소를 포함하고 있는 보고서를 
인쇄하는 부분프로그람은 코드화되지 않았다. 이것은 신속원형작성림에 있어서 좋은 
결정 으로 되 는가? 당신은 대 답을 안받침 하기 위하여 비 여 있는 부분프로그람의 몸체부를 
완성 하시 오. 

10.16. (쏘프트웨 어 공학독본) 교원 이 문 헌 [karlsson and Ryan , 199기의 복제 본을 
배포할것이다. Karlsson 과 Ryan 방법을 비용 대 리득분석에 기초하여 완성된 생명주기 
모형으로 어떻게 확장할수 있는가? 
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제 1 1 장. 명세작성단계 


명세서는 두개의 서로 모순되는 요구를 만족시켜야 한다. 한편 명세서는 콤퓨터전문 
가는 아닐수도 있는 의뢰자에게 명백하고 리해하기 쉬워야 한다. 결국은 의뢰자가 제품 
에 값을 지 불하는데 그가 새 제 품이 어 떤것 으로 될것 인가를 실지 로 리 해 하지 못한다면 
그는 그 제품의 개발을 맡기지 않기로 결심하든가 또는 다른 쏘프트웨어개발기업체를 청 
하여 그것을 개 발하도록 할 가능성 이 크다. 

다른 한편 명세서는 설계를 작성하는데 쓰이는 유일한 정보원천이기때문에 완전하고 
세부적이여야 한다. 비록 의뢰자가 요구사항확정단계에서 모든 요구들이 정확하게 결정 
되였다고 동의하여도 만일 명세서가 생략，모순, 애매성과 같은 오유를 포함하면 실현에 
로 넘어 갈 설계에서 불가피하게 오유결과가 생기게 될것이다. 그렇기때문에 의뢰자가 
리해하기 쉽도록 충분히 비공학적 이면서도 생명주기의 마감에 의뢰자에게 오유 없는 제 
품이 배포되도록 충분히 정확한 형식으로 목적하는 제품을 표현하는 기법이 필요된다. 
이와 같은 명세작성기법이 바로 이 장과 다음장의 주제이다. 이 장에서는 고전적(구조화 
된) 명세작성기법 에 중점을 두며 12장에서는 객체지향분석 에 전심한다. 

11. 1 . 명세서 

명세서는 의뢰 자와 개 발자사이의 계 약서 이다. 명세서 에는 제품이 하여 야 할것과 그 
제 품에 대 한 제 약을 명 기한다. 사실 매 명세서 들은 제 품이 만족시 켜 야 할 제 약을 포함하 
고 있다. 거의 언제 나 제품을 배포하기 위한 최 종기 한이 명 기된다. 또 하나의 공통계 약은 
다음과 같다. 의뢰자는 새 제품들이 실지로 명세서의 모든 측면을 만족시킨다고 할 때까 
지 《제품은 현존 제품과 병렬로 실행할수 있는 방식으로 설치될것이다》. 기타 제약들은 
이 식성을 포함할수도 있다. 즉 제품은 갈은 조작체 계 들을 리용하는 다른 하드웨 어상에서 
동작하거 나 각이한 조작체 계 들에 서 동작할수 있도록 구성 되 여 야 한다는것 이 다. 신뢰 성 이 
또 하나의 제약으로 될수도 있다. 만일 해당 제품이 집중치료실에서 환자를 감시하여야 
한다면 하루 24 h 전적으로 동작하는것이 가장 중요하다. 응답시간이 요구로 될수 있다. 
이 범주에서 전형적인 제약은 《형식 4에 대한 95%의 질문들은 0.25 s 이내에서 답변될것 
이 다.》로 될수 있다. 대 다수의 응답시 간제 약들은 응답시간이 콤퓨터의 현재 부하에 의존 
하기 때 문에 확률적 인 용어 로서 표현되 여 야 한다. 반대 로 이 른바 장치실 시 간제 약들은 절 
대적인 술어 로 표현된다. 실례 로 전투기 에 날아 오는 미싸일을 장치실시 간의 95%에 해 
당한 0.25 s 이 내 에 통지하는 프로그람은 쓸모 없 다. 제 품은 장치 실 시 간에 대 한 100%의 제 
약을 만족시켜야 한다. 명세서의 중요한 요소는 합격판정기준모임이다. 의뢰자에게 제품 
이 명세서 를 실지 로 만족시키 며 또 개 발자의 임 무가 수행된다는것 을 증명하는데 리용할 
수 있는 일 련의 시 험을 자세 히 해석하는것은 개 발자와 의뢰 자의 관점 에서 모두 중요하다. 

일부 합격판정 기 준들은 제 약에 대 한 재 설명 으로 될수 있으며 반면에 기 타 판정 기 준 
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들은 여러가지 론의를 거처야 한다. 실례로 의뢰자는 개발자에게 제품이 조종할 자료들 
에 대한 서술을 제공할수 있다. 그러면 그 제품이 이 류형의 자료를 정확하게 처리하고 
적 합치 않은(즉 오유) 자료들을 려과해 내는것 이 적 당한 합격판정기준으로 될수 있다. 일 
단 개발림이 문제를 완전히 리해하면 가능한 해결전략이 제안될수 있다. 해결전략 
(solution s / ra / egy ) 이 란 제품을 만들기 위 한 일반적 방법 이 다. 실례 로 어떤 제품에 대한 한 
가지 가능한 해 결 전 략은 직 결 식자료기 지 를 리용하는것 일 수 있 으며 또 다른 해 결 전 략은 
습관적 인 단층파일 을 리 용하고 철 야묶음실 행 을 리용하여 필 요한 정 보를 추출하는것 일 수 
도 있다. 해결전략을 결정할 때 명세서에 있는 제약들을 념려하지 않고 전략을 제의하는 
것이 좋은 방법이다. 그러면 각이한 해결전략들을 제약의 관점에서 평가할수 있고 필요 
한 변경 을 진행할수 있다. 어떤 특정한 해 결전략이 의뢰 자의 제 약들을 만족시 킬것 인가를 
결정 하는데 는 여 러 가지 방법 이 있 다. 한가지 명 백 한것 은 원형 작성 인데 이 것 은 3.7 에 서 이 
미 론의한바와 같이 사용자대면부들과 시간제약들과 관계된 론점들을 해결하기 위한좋 
은 기법으로 될수 있다. 제약들이 만족될것인가를 결정하기 위한 기타 기법들은 모의 
[ Banks , Carson , Nelson , Nichol , 200 이와 해 석 적 망모형 화 [Kleinrock and Gail , 1996] 를 포함 
하고 있다. 

이 과정 에서 많은 해결전략들이 제시되 고 그다음 버 려 질것 이다. 버 려 진 모든 전략 
들과 그것 들이 버 려 진 리유를 적 은 기 록을 보관하여 두는것 이 중요하다. 이 것은 만일 
선택된 전략을 정 당화하기 위하여 그 기록들을 다시 보게 되는 경 우에 개발림 을 도와 주 
게 될 것 이 다. 그러 나 보다 중요하게 는 유지 정 비단계 에 서 항시 적 으로 나타나는 한가지 위 
험이 존재한다. 즉 어떤 새롭고 현명치 못한 해결전략을 제의하려는 시도와 함께 확장과 
정이 생겨 나게 된다. 개발기간에 어떤 전략들이 기각되는 원인을 기록해 놓는것은 유지 
정 비 단계 에 서 매 우 쓸모 있 다. 

이러한 견지로부터 개발림은 제약들을 만족시키는 하나 또는 그이상의 가능한 풀이 
전략들을 결정하는것 이 다. 두단계 결정 이 만들어 져 야 한다. 첫째 로，의 뢰 자에 게 콤퓨터 화 
를 진행할것을 권고하여야 하는가 하는것인데 만약 권고한다면 어느 해결전략을 채용하 
여 야 하는가를 결정한다. 첫 번째문제 에 대 한 답변은 비 용 대 리 득분석 (5.2) 에 기 초하여 
가장 훌륭히 결정될수 있다. 

둘째 로, 만일 의뢰 자가 프로젝트를 실행해 나가기 로 결정 한다면 의뢰 자는 개발림 에 
의뢰 자의 총적비용을 최소로 한다든가 또는 투자에 대 한 리윤을 최대로 한다든가와 갈은 
리용될 최 량화관정기준을 알려 주어야 한다. 개발자들은 그러면 의뢰자에게 어느 해결전 
략이 그 최 량화기 준을 가장 만족시 키 는가를 통지한다. 

11.2. 비형식적명세작성 

개발프로젝트들에서 명세서는 여러폐지의 영어 또는 프랑스어나 코사어와 같은 민족 
어로써 구성된다. 전형적인 명세서의 한 단락을 다음과 같이 제시한다. 

BV .4.2.5 만일 이달 매상고가 목표매상고보다 낮다면,..불고서를 찍으며 목표매상고와 실제매 
상고사이 차가 전달의 목표매상고와 실제매상고사이 차의 절반보다 작지 않다면 또는 목표 
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매상고와 이달의 실제매상고사이 차가 5%이하라면 보고서를 찍는다. 

이 단락의 배경은 다음과 같다. 련쇄된 소매상점들에 대한 관리자측은 매 상점에 관 
한 매달 목표매상고를 설정하며 만일 어떤 상점이 이 목표를 만족시키지 못하면 보고서 
가 인쇄되게 된다. 다음과 같은 대본을 고찰하자. 가령 1월달 어떤 상점의 판매목표가 10 
만딸라인데 실제 매 상고는 6 만 4 천딸라이라고 하자. 즉 목표보다 36% 낮다. 이 경 우에 
보고서 가 인쇄 되 여 야 한다. 이 제 2월달 목표매 상고는 12만딸라이 며 실제매 상고는 겨 우 
m 만딸라이라고 가정 하자. 즉 목표보다 16.7% 낮다. 비 록 판매 액 이 목표보다 낮지 만 2 월 
달 퍼센트차 16.7% 는 전달의 36% 의 절반보다 적으며 따라서 관리자측은 일정한 개선이 
있 다고 믿 고 보고서 를 인쇄하지 않는다. 다음으로 3 월달에 목표는 10 만딸라이 지 만 상점 
에서 판매액이 9 만 8 천딸라로서 목표보다 다만 2% 낮다고 가정하자. 퍼센트차가 5% 보다 
적으므로 보고서는 인쇄되지 말아야 한다. 

고찰하고 있는 명세서단락을 주의 깊게 다시 읽으면 련쇄된 소매상점관리 자측이 실 
지 요구 하는것으로부터 좀 탈선하였다는것을 알수 있다. BV . 4.2.5 단락에서는 목표매상 
고와 실제매 상고사이차에 대 하여 말하고 퍼 센트차는 언급하지 않고 있다. 1월 달에 그 차 
는 36,000딸라 2월달에 는 200,000딸라이다. 관리 자측이 요구 하는 퍼 센트차는 1월 달에 
36%부터 2월달에 16.7% 떨어 졌다. 그러 나 실제차는 36,000로부터 2,000딸라로 떨어 졌 
으며 이것은 36,000딸라의 절반보다 더 크다. 그러 므로 만일 개발림 이 요구 명세서를 충실 
히 실현하였 다면 보고서를 인쇄해 야 하였는데 이것은 관리 자측이 바라는것 이 아니 다. 

그다음 마지막절에서는 《•••[의]차가 5%》라고 말하고 있는데 이것은 물론 5%의 
퍼센트차를 의미 하고 있으며 다만 단어 퍼센트가 요구명세서단락의 어 디 에서도 나타나지 
않은것 이 다. 

그렇 기때 문에 명세서 에는 많은 오유를 포함하고 있다. 

첫째 로, 의뢰 자가 원하는것 이 무시되 였으며 둘째 로, 애매성 이 존재한다. 즉 마지 막 
절은《•••[의] 퍼센트차가 5%》든지 《…의 차는 5,000딸라》이라고 읽어야 한다. 그 
밖에 형식이 불충분하다. 이 단락이 말하고 있는것은 《만일 무슨 현상이 일어 나면 
보고서 를 인쇄하라. 그러 나 만일 그밖에 무슨 현상이 일 어 나면 그것 을 인쇄하지 말 
라. 그리 고 만일 세번째 현상이 일 어 나면 보고서 를 인쇄하지 말라.》이 다. 만일 이 
명세서 가 보고서 가 언제 인쇄되 야 하는가를 간단히 서 술하였더 라면 훨씬 명 백하였을 
것 이 다. 결국 단락 BV .4.2.5 는 명세서를 어 떻게 작성하여 야 하는가에 대 한 그리 좋은 
실례로는 되지 않는다. 

사실 BV .4.2.5 는 허구적이지만 공교롭게도 아주 많은 요구서들에서 전형적인것이다. 
이 실례가 부적당하며 이러한 부류의 문제는 명세서를 전문명세작성자가 주의 깊게 작 
성한다면 생기지 않을수 있다고 생각할수 있다. 이러한 론의를 반박하기 위하여 제6장 
의 실례연구를 여 기서 다시 시 작하기 로 한다. 

11. 2. 1 • 실례연구 : 본문처리 

6.5.2 로부터 1969년에 나우르가 정 확성증명 에 관한 론문을 썼 다는것 을 상기하자 [ Naur , 
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1969]. 그는 자기의 기법을 본문처리문제로써 례증하였다. 이 기법을 리용하여 나우르는 
이 문제를 해결하기 위한 ALGOL 60 절차를 작성하였으며 이 절차의 정 확성을 비형식적으 
로 증명하였 다. 나우르 ( Naur ) 의 론문에 대 한 조사자들은 이 절 차에 서 한가지 오유를 지 적 
하였 다 [ Leavenworth , 1970]. 론돈은 그이 후 나우르의 절 차에 서 3개 의 보충적 인 오유를 발 
견하고 정 확한 절 차를 제 시 하고 그것의 정 확성을 형 식적 으로 증명하였다 [ London , 19기]. 
구데 나우 ( Goodenough ) 와 게 르하르트 ( Gerhart ) 는 그이 후 론돈 ( London ) 이 찾지 못한 3개 의 
오유를 더 찾아 냈다 [Goodenough and Gerhart , 1975]. 론돈，구데 나우와 게 르하르트와 같 
은 조사자들이 찾아 낸 총 7개 의 오유가운데 서 두개 는 명 세작성오유로서 고찰할수 있 다. 
실례로 나우르의 명세서는 입력이 두개의 련이은 중단점(공백 또는 개행문자)들을 포함 
하면 무슨 현상이 일 어 나는가를 설 명하지 않고 있 다. 이 리유로 하여 구데 나우와 게 르 
아르트는 새 로운 명세서모임 을 만들어 냈다. 그들의 명세서는 6.5.2 에 제 시된 나우르의 
명세서보다 약 4배 더 길 다. 

1985년이 메이어 ( Meyer ) 는 형식적명세작성기법에 대한 론문을 썼다 [ Meyer , 1985]. 
이 론문에 대한 중요한 혹평은 명세서가 영어와 같은 자연언어로 작성되여 모순, 애매 
성，생략을 가질수 있다는것이다. 그는 명세서를 형식적으로 표현하기 위하여 수학적용 
어를 리용할것을 권고하였다. 메 이 어는 구데 나우와 게 르하르트의 명세서 에서 12개의 
오유를 찾고 이 문제를 수정하기 위한 수학적명세서모임을 개발하였다. 그다음 메이어 
는 자기의 수학적명세서를 의역하여 영어로 된 명세서로 작성하였다. 우리의 견해에 
의하면 메 이 어의 영 어명세서는 한가지 오유를 포함하고 있다. 메 이 어는 자기의 론문에 
서 만일 행 당 최 대문자수가 …이 고 실례 로 입 력문장이 WHO WHAT WHEN 이 면 나우 
르 및 구데나우와 게르하르트의 명세서에 관하여 두개의 등가적으로 타당한 출력이 존 
재한다는것 을 지 적하였 다. 즉 첫 행 에서의 WHO WHAT 와 두번째 행 에서의 WHEN 또 
는 첫행에서의 WHO 와 두번째 행에서의 WHAT WHEN 은 등가이다. 사실 메이어가 의 
역한 영어명세서도 이러한 애매성을 포함하고 있다. 

중요한것은 구데나우와 게르하르트의 명세서가 최대의 심중성을 가지고 작성되였다 
는것 이 다. 결국 그것 들은 나우르의 명세서 를 수정 하기 위하여 작성 되 였 다. 더 우기 구데 나 
우와 게르하르트의 론문은 두개의 판본으로 출판되 였는데 첫번째 는 련관된 대회회보에 
출판되였고 두번째는 련관된 잡지에 출판되였다 [Goodenough and Gerhart , 1975]. 결국 구 
데 나우와 게 르하르트는 둘 다 일 반적 으로는 쏘프트웨 어공학의 전문가들이 고 개 별적 으로 
는 명세작성 자들이 다. 그러 므로 만일 두명 의 전문가들이 자기들이 요구한 시 간을 가지 고 
메이어가 12개의 오유를 발견한 명세서를 주의 깊게 만들었다면 주어 진 시간하에서 작 
업하는 일반콤퓨터전문가는 오유 없는 명세서를 작성하는데 얼마만한 기회 를 가질수 있 
는가? 보다 나쁘게 는 본문처 리 문제 는 25 또는 30행 으로 코드화될 수 있지 만 실세계 제품은 
수만 지어는 수백만행의 원천코드로 구성될수 있다. 

명백히 자연언어는 제품을 평가하기 위한 좋은 방법으로 되지 않는다. 이 장에서는 
보다 좋은 대응방법 이 고찰된다. 명세작성 기법을 비형식적 인것으로부터 보다 형식적 인것 
을 서 술하는 형 식 으로 설 명한다. 
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11.3. 구조화체계분석 

쏘프트웨 어를 명기하기 위하여 도형을 리용한것은 1970 년대의 중요한 기법이였다. 
도형를 리 용하는 3 개의 기법이 특히 보편적 이였는데 그것들의 데마르코 [DeMarco, 1978], 
게 인과 사르센 [Gane and Sarsen, 1979], 요르돈과 콘스탄린 [Yourdon and Constantin, 1979] 
의 기법이다. 이 세가지 기법은 모두 동등하게 좋으며 본질적으로 등가이다. 게인과 사르 
센의 표시 법 이 산업 에 서 현재 가장 광범히 리 용되 고 있기때 문에 그들의 방법 을 제 시한다. 

이 방법 을 리해 하기 위하여 다음의 실례 를 고찰하자. 

11. 3. 1 • 쏘프트웨어상점 

쌜 리 (Salley) 의 쏘프트웨 어 상점 은 여 러 공급자들로부터 쏘프트웨어 들을 사들이여 판 
매한다. 쌜리는 대중적 인 쏘프트웨 어패키지들을 사들이며 필요할 때 다른 제품들을 주문 
한다. 쌜리는 보험회사，주식회사, 일부 개별적사람들에게 신용대부를 확장한다. 쌜리의 
쏘프트웨어상점은 경기가 좋은데 개당 250 딸라의 평균소매가격으로서 매달 300 패키지의 
쏘프트웨어를 넘 긴다. 기 업운영 에서 성공하고 있음에도 불구하고 쌜리는 를퓨터화를 실 
현하라는 권고를 받았다. 쌜리가 콤퓨터화를 하여야 하는가? 

서 술한바와 같이 이 문제 는 적 당치 않다. 다음과 갈은것 을 해 석하여 야 한다. 다음 
의 업 무기 능 즉 지 출능력계 산，수용능력계 산, 제 품목록 등에 서 어 느 업 무기 능들을 콤퓨터 
화해야 하는가? 비록 그것이 충분치 않다고 하더라도 체계는 계렬처리식으로 되여야 하 
는가 직결식으로 되여야 하는가? 

국내를퓨터체계로 되여야 하는가 아니면 해외조달로 리용되여야 하는가? 비록 문제 
가 더 세 련된 다고 할지 라도 여 전히 기본론점 은 놓치 고 있 다. 즉 업 무를 콤퓨터화할 때 
쌜 리 의 목적 이 무엇 인 가 하는것 이 다. 

쌜리의 목적이 알려 질 때에만 분석을 계속해 나갈수 있다. 실례로 그 녀자가 쏘프 
트웨어 를 팔기 때 문에 단순히 콤퓨터 화를 하려 고 한다면 그는 콤퓨터 의 능력 들을 화려하 
게 돋보이 게 하는 여 러 가지 음향 및 빛효과를 가진 실내콤퓨터체계를 요구한다. 다른 한 
편 만일 쌜 리 가《부당한》돈을 세척할 목적 으로 자기 업무를 리용하려 한다면 네댓개의 
서 로 다른 장부책 을 만들어 놓고 아무런 결산결 과도 남기 지 않는 쏘프트웨어 제 품을 요구 
한다. 

이 실례 에서는 쌜 리 가《더 많은 돈을 벌기 위하여》를퓨터화를 진행하려 고 한다고 
가정하고 있다. 이것이 그리 도움이 되지 않지만 비용 대 리득분석이 이 세개의 업무항 
목모두(또는 어느 하나)를 콤퓨터화하겠는가를 결정할수 있다는것은 명백하다. 

여러가지 표준적인 방법들에서 제기되는 중요한 위험성은 사람들이 이를테면 10GB 
의 Lime III 를퓨터 와 레이 자인쇄 기 와 같은 해 결 방안을 먼저 제 기 하고 문제 는 후에 찾아 
내려고 한다는것이다. 반대로 게인과 사르센은 9 계단 기술을 리용하여 의뢰자의 요구를 
분석 한다 [Gane and Sarsen , 1979]. 한가지 중요한 점 은 계 단식 세 련(개 량)이 이 9 계 단의 대 
부분에서 리용된다는것이다. 이것은 이 기법이 현시될 때 지적될것이다. 

쌜리의 요구를 결정할 때 구조화분석의 첫 단계는 물리 적자료흐름에 대 립하는것으로 
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서 론리 적 자료흐름 (/o 판 ca/ data _/7ow) 을 결정 하는것 이 다(즉 그것 이 어 떻게 발생 했는가에 
대 립하는것 으로서 무엇 이 발생했는가 하는것 이 다.). 이 것은 자료흐름도 (DFD) 를 작성 함으 
로써 수행 된 다. DFD 는 그림 11-1 에 보여 준 4개 의 기 본기호를 리용한다(게 인과 사르센 
의 표시법은 데마르코 [DeMarco, 1978] 과 요르돈과 콘스탄린 [Yourdon and Constantine, 
1979] 의 표시 법과 류사하지만 리상적 이 아니 다.). 

1 단계 . DFD 를 작성한다 임의의 단순하지 않은 제품에 대한 DFD 는 규모가 클수 있다. 
DFD 는 론리 적자료흐름의 모든 측면들에 대 한 하나의 그림 표현 이 며 그것 은 또 7士2보다 
상당히 많은 요소들을 포함한다고 약속되여 있다. 이러한 리유로 하여 DFD 는 계단식세 
련방법 (5.1) 으로 개발되여 야 한다. 


자로의 원천.또는 
목적지 


자로의 흐름 


2 중 

정사각형 


화살 


( 둥그런 ] 자로의 흐롬을 
^ 직사각형 \ 전송하는 과정 


끝이 열린 
직사각형 


자료의 저장 


그림 11-1. 게 인과 사르센의 구조화체 계분석 의 기 호 

자료흐름도는 요구문서나 신속원형내에서 자료의 흐름을 인식함으로써 구성된다. 자 
료의 매 개 별적흐름은 자료원천-목적 지 (2 중정 사각형 통으로 표시된다.)든가 자료의 저 장 
(끝이 열린 직 사각형 으로 표시 된다.)으로 시 작되 고 끝난다. 자료는 하나 또는 그이 상의 
공정(둥그런 직사각형 으로 표시)에 의하여 변환된다. 매 련속적 인 세 련에서 자료의 새 로 
운 흐름이 DFD 에 추가되든가 보다 세부적 인 사항을 추가하는것으로써 자료의 현존흐름 
이 개선된다. 

실례를 고찰하자. 첫번째 개선을 그림 11-2 에 보여 주었다. 이 론리적자료흐름은 여 
러가지 로 해 석할수 있 다. 두가지 가능한 실현은 다음과 갈다. 

실 현 1에 서 자료저 장패 키 지자료는 책 상서 랍안에 있 는 많은 사용설 명 서 들과 사전에 
전시된 디스크나 CD 판들이 들어 있는 약 900개의 수축포장한 통들로 구성된다. 자료저 
장 손님 자료는 고무띠로 묶은 5X7” 카드들의 모임이며 거기에 지불기간이 넘은 손님들에 
대한 목록이 더해 졌다. 과정(작용) 주문처리는 쌜리가 시렁우에 놓인 적당한 패키지를 찾 
는것인데 만일 그것을 사용설명서에서 찾는것이 필요하다면 정확한 5 X 7’ 카드를 찾고 손 
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DFD 에 추가된다. 특히 그 패키지에 대한 세부자료는 자료저장 미결한 주문 
있는데 이 것은 하나의 콤퓨터파일일수 있지 만 이 단계 에서 는 충분히 마닐 라 
b ! der ) 일수 있다. 자료저장 미결한 주문은 콤퓨터 또는 쌜리가 매일 조사하며 
공급자에게 충분한 주문이 있다면 하나의 계렬처 리주문이 놓이게 된다. 또 
주문이 5일동안 대기되였다면 아무리 많은 패키지들이 련관된 공급자들로 
자를 기다리고 있다 하여도 그것이 주문된다. 이 DFD 는 쏘프트웨어패키지 
-급자로부터 출발하는가 하는 론리 적자료흐름을 보여 주지 않으며 또 지 불 
-능력 과 같은 기 능들을 보여 주지 않는다. 이 것 들은 세번째 세 련단계 에 서 

^■모가 크기 때 문에 그림 11-4 에 서 는 세번째 단계 의 일 부분만을 제 시한다. 이 
수용능력 과 관계 되 는 자료의 론리 적흐름이 DFD 에 추가된다. DFD 의 나머 
불능력 과 쏘프트웨 어 공급자들에 게 관계 되 여 있 다. 


패 키 지 자료 


주문된 체키지세부 







최종적인 DFD 는 여전히 크며 대략 6페지에 달한다. 그러나 쌜리에게 그것은 쉽게 
리해될것이다. 쌜리는 그것이 자기 업무에서의 자료의 론리적흐름을 정확히 표현하고 있 
다고 확인하면서 거기 에 수표를 한다 (11. 14은 DFD 를 구성하는 방법 에 대 한 서술을 포함 
한다.:). 

제품이 크면 콜수록 DFD 는 더 커지게 된다. 

이 절에 서 우리 는 쌜리의 쏘프트웨 어 상점 을 위한 DFD 의 구성 을 제 시하였 다. 자료흐 
름도의 구성 에 대 한 보다 자세한 실례는 11. 14에 서술한다. 

2단계. 어느 부분을 어떻게 (계렬처리식 또는 직결식으로) 콤퓨터화하겠는가를 결정한다 

무엇을 자동화하겠는가 하는 선택은 흔히 얼마나 많은 의뢰자에게 보내기 위하여 준비하 
여야 하는가에 의존한다. 명백히 전체 조작을 자동화하는것이 좋지만 이에 드는 비용이 
너무 많다. 어느 부분을 자동화하겠는가를 결정하기 위하여 매 부분을 콤퓨터화하기 위 
한 여러가지 가능한 단계들에 비용 대 리득분석이 적용된다. 실례로 DFD 의 매 부분에 
대 하여 조작들의 묶음이 계 렬 처 리식 으로 수행 되 여 야 하는가 직 결 식 으로 수행 되 여 야 하는 
가를 결정하여 야 한다. 처 리 할 량이 크고 안정한 조종이 요구될 때 에는 흔히 계 렬식처 리 
가 좋지만 처리할 량이 작고 실내콤퓨터체계라면 직결식처리가 더 좋을수 있다. 고찰하 
는 실례 에서 한가지 대 책안은 지불능력 을 계 렬처 리식 으로 자동화하고 주문을 직결식 으로 
비 준하는것 이 다. 두번째 대 책안은 주문을 직 결 또는 계 렬 식 으로 처 리하는것 에 대 처하여 
쏘프트웨 어공급자의 위 탁판매문서 들의 편집 을 비 롯하여 모든것 을 자동화하고 나머 지 조작 
들을 직결식으로 처리하는것이다. 중요한 점은 DFD 가 앞에서 설명한 모든 가능성에 대 
응한다는것 이 다. 이것은 설계단계 까지 기 다리지 않고 명세작성단계 에서 문제를 해결하기 
위한 방법 에 관하여 전 념하지 않는것 과 일 치한다. 

게인과 사르센의 기법의 다음 세단계는 자료의 흐름(화살표)，처리(둥근사각형), 자료 
저 장(열린 사각형 )의 계 단식 세 련 이다. 

3단계. 자료흐■의 세부를 결정한다 우선 무슨 자료항목들을 각이한 자료흐름안에 
넣어야 하는가를 결정한다. 그다음 매개의 흐름을 계단식으로 세련시킨다. 

실례에서 자료흐름 order 는 다음과 같이 세련될수 있다. 

order : 

order identification 
customer details 
package details 

다음으로 우에 서술한 order 의 매 요소들을 더욱 세련시킨다. 규모가 큰 제품인 경우 
에 자료사전 (5.4) 에 모든 자료요소들의 통로를 보관해 둘수 있다. 그림 11-5 는 쌜리의 生 
프트웨어상점 을 를퓨터화하는데서 필요한 자료요소들에 대 한 전형 적 인 정 보를 보여 주고 
있는데 그것은 자료사전안에 저장되게 된다. 

4단계. 처리의 론리를 결정한다 제품안의 자료요소들이 결정되였다고 하면 다음은 
매 처리공정에서 무엇이 발생하는가를 연구해야 한다. 실례로 하나의 처리공정 교육단체에 
할인을 준 다를 고찰하자. 쌜 리는 쏘프트웨 어개 발자들에게 자기 가 교육단체 에 줄 할인액 에 
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대한 세부를 제공하여야 한다. 실례로 4개까지의 패키지에 대하여서는 10%, 5개이상에 
대 하여서 는 15% 등으로 준다. 자연언어 로 된 명세 서 의 난점 에 대 처 하기 위하여 그것 을 
문장으로부터 결정나무로 변환하여야 한다. 이와 갈은 결정나무를 그림 11-6 에 보여 주 
었 다. 


자료요소의 이름 

식 별 

해 설 

order 

포함하는 항목: 

orderidentification 

customerdetails 

이 항목들은 주문의 모든 세부를 포함 
한다 


customeraddres s 



package_details 

package_name 

package_address 


orderidentification 

12 자리 옹근수 

절 차 generate_order_number 에 의하여 
생성되는 유일한 수 

첫 10 개 수자는 주문개수를 나타내 고 
마지 막 2 개 수자는 검 사수자이다. 

verifyorderisvalid 

처 리 절 차: 

입 력 파라메 터 : 

order 

출력파라메터: 

number of errors 

이 절차는 입력이 order 이고 매 항목의 

타당성을 검사한다. 발견된 매 오유에 
대하여 적당한 통보문이 화면에 현시 
된다(발견된 전체 오유수는 파라메터 
number of errors 를 되돌린다.). 


그림 11-5. 쌜 리의 쏘프트웨 어상점 을 위한 대 표적 인 자료사전입 력점 

결정 나무는 모든 가능성 들이 고려되 였 다는것 을 쉽 게 검 사할수 있게 하는데 특히 복 
잡한 경우에는 더욱 그렇다. 한가지 실례를 그림 11-7 에 보여 주었다. 그림 11-7 로부터 
꼴문구역 에 있는 좌석 에 앉는 학생 에 대 한 가격 이 명시되지 않았다는것 이 인차 명백하여 
진다. 처 리 공정 을 표현하기 위 한 또 한가지 좋은 방법 은 결정 표를 작성하는것 이 다 [Poll 
ack , Hicks and Harrison , 19 기]. 결정 표는 일 부 CASE 도구들이 결 정 표의 내 용들을 자동적 
으로 콤퓨터 에 입 력되게 하므로 제 품에서 그 부분에 대 하여서는 코드로 작성할 필요가 
없 다는 점 에 서 결 정 나무보다 우월 성 을 가진 다. 

5단계. 자료저장을 정의한다 이 단계에서는 매 저장의 정확한 내용과 그것의 표현방 
법 (형 식)을 정 의하는것 이 필 요하다. 결국 만일 제 품이 COBOL 로 실현되 게 된다면 이 정 
보는 pic 준위 아래 에 서 주어 져 야 한다. 만일 Ada 가 리 용된다면 digits 또는 delta 로 명 시 
되 여 야 한다. 게 다가 즉시 접 근이 어 디 에 서 요구되 는가를 명 시 하는것 이 필 요하다. 
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교육단체에 대한 할인을 준다 


교육단체 

、、기타 : 0% 


<4 패키지 :10% 

〈w 


그림 11-6. 쌜리의 쏘프트웨어상점의 교육단체에 대한 할인을 나타내는 결정나무 



40야드선구역 :20딸라 
꼴문구역 : 12딸라 


40야드선구역 :40딸라 


그림 11-7. 단과대 학축구경 기관람석값을 나타내 는 결정 나무 


즉시 접 근 (/ mmec 加 access )^] 대 한 론의 는 무슨 질 문들이 제 품에 첨 부되 게 되 여 있는 
가에 관련되여 있다. 례하면 실례에서는 주문을 직결식으로 비준한다고 결정되여 있다고 
가정 하자. 

손님은 이름(《 당신은 Lotus 1-2-3 을 재고품으로 가지고 있는가.》), 기능(《무슨 
회계프로그람묶음을 가지고 있는가?》), 기계(《당신은 786을 위한 무슨 새로운 제품을 
가지고 있는가?》)로 프로그람묶음을 주문할수 있지만 가격(《무슨 149.50 딸라짜리계 
품을 가지고 있는가?》)으로는 거의 주문하지 않는다. 그렇기때문에 패키지자료에 대 
한 즉시접근은 이름，기능, 기계를 요구한다. 

이것은 그림 11-8 의 자료즉시 접 근도 ( DIAD ) 에 묘사된다. 


이름 


1 기능 1— ► 

패 키 지 자료 

< -1 기 계 


이름 


가격 

기능 

기계 


그림 11-8. 패 키지자료를 위한 자료즉시접 근도 ( DIAD ) 

6 단계 . 물리적자원을 정의한다 이제 개발자가 무엇이 직결식으로 요구되는가와 매 
요소들의 표현(형 식 )을 알고 있 다고 하면 블로크화인수 ( WocJb > jg / actor ) 를 고려하여 한가 
지 결정 을 할수 있 다. 더 우기 매 파일 에 대 하여 다음의 사항을 명 시할수 있 다. 즉 파일 이 
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름，조직 , 기 억 매 체，마당준위 아래 의 기 록들을 명 시 한다. 만일 자료기 지 관리 체 계 ( DBMS ) 가 
리용된다면 매 표에 대 한 관계 정 보는 이 단계 에서 명 시 된다. 

7단계. 입력출력명세서를 결정한다 만일 명세서륜곽이 자세하지 않다면 적어도 요소 
들에 관하여 입력형식들을 명시하여야 한다. 입력화면들이 류사하게 결정되여야 한다. 인 
쇄되는 출력도 가능한한 상세하게 명시되여야 하며 한편 길이가 평가되여야 한다. 

8단계 . 규격을 결정한다 9단계 에 서 장치 적 요구들을 결 정하는데 리 용될 수값자료를 계 
산하는것이 필요하다. 이 자료들을 입력의 크기(날자적으로 또는 시간적으로)，매 인쇄보 
고서 의 빈도와 기 한， CPU 와 대 용량기 억 장치사이 를 통과하게 될 매 류형 의 레 코드크기 와 
개수, 매 파일의 크기를 포함하고 있다. 

9단계. 장치적요구들을 결정한다 8단계에서 결정된 디스크파일에 있는 규격정보로 
부터 대용량기 억장치 에 대한 요구를 계산할수 있다. 게 다가 여벌복사(如를 위한 대 
용량기 억 장치요구들을 결정할수 있다. 입 력크기 에 대 한 지 식 으로부터 이 분야에 서 의 요 
구가 발견될수 있다. 인쇄보고서의 행수와 빈도가 알려 지기때문에 출력장치들이 명시될 
수 있다. 만일 의 뢰 자가 이 미 장치 들을 가지 고 있 다면 이 장치 들이 적 당할것 인 가 또는 
추가적 인 장치 들을 구입해 야 하는가가 결정 될수 있다. 다른 한편 만일 의 뢰 자에 게 적 합 
한 장치 가 부족하다면 무엇 을 얻 어 야 하며 그것 을 구입해 야 하는가 빌 러 씨 야 하는가에 
대 한 권고를 명 시할수 있 다. 

장치적요구를 결정하는것은 게 인과 사르센의 명세작성기법에서 최종단계이며 이 
실례를 아래의 란에 개 괄하여 준다. 의 뢰 자가 찬성 한다면 결과적 인 명세서 를 설계하 
여 넘 겨 주며 쏘프트웨 어개 발공정 을 계 속 수행한다. 많은 장점 이 있음에 도 불구하고 
게인과 사르센의 기법은 모든 문제들에 답변을 주지는 못한다. 실례로 이 기법은 응답시 
간을 결정하는데 리용될수 없 다. 입 력-출력 통로의 수는 기껏 해 야 대 략적 으로 평 가될수 
있다. 또한 CPU 의 규격과 박자는 임의의 정확도로 평가될수 없다. 이것들이 게인과 사르 
센의 기법에 고유한 약점인데 공정하게 말하면 이것은 사실상 다른 모든 명세작성이나 
설계의 약점이기도 하다. 그러나 명세작성단계의 끝에서 정확한 정보를 리용할수 있든지 
없든지간에 장치 적 결정 을 하여 야 한다. 이 와 관련한 정 황은 과거 에 진행한것 보다는 상당 
히 락관적 이다. 명세작성 을 위한 방법론적 기 법 이 제 기되기전에 쏘프트개 발공정의 시 작단 
계 에서 장치를 고려한 결정들이 옳게 채 택되 였다. 게 인과 사르센의 기법은 제품을 명시 
하는 방법에서 중요한 개선을 가져 왔으며 게인과 사르센 그리고 그 기법과 경쟁하고 있 
는 대다수 저자들이 시간을 변수로서 본질적으로 무시하고 있다는 사실은 쏘프트웨어산 
업 이 가져 온 우점 들을 약화시키 지 않고 있 다. 


구조 Sh 체계분석방법 

• 자료흐름도를 작성 한다. 

•무슨 부분을 어떻게(계렬처리식 £는 
직결식) 를퓨터화하는가를 결정 a 다. 

• 자료흐름의 세부를 결정한다. 

• 처리의 론리를 정의한다. 


• 자료저 장을 정 의 한다. 

• 물리적자원을 정의 한다. 

• 입력-출력명세서를 결정한다. 

• 규격화를 진행 한다. 

• 장치적요구를 결정 한다. 
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11.4. 기타 준형식적기법 

게인과 사르센의 기법은 명백히 명세서를 자연언어로 작성하는것보다는 더 형식적이 
다. 동시 에 그것 은 다음의 론의 에 서 제 시하는 페 트리 망 (11.7) 과 Z (11.8) 와 같은 많은 기 법 
들보다는 덜 형식적이다. 다트와 그의 동업자들은 명세서 및 설계작성기법을 비형식적， 
준형식적，형식적인것으로 분류하고 있다 [ Dart , Ellison , Feiler and Habermann , 198 刀. 이 
분류에 의하여 게 인과 사르센의 구조화체 계분석 은 준형식 적 기법 으로 되 며 반면 에 이 단 
탁에서 언급하는 다른 두가지 기 법들은 형 식적기 법들로 된다. 

구조화체 계 분석 이 광범히 리용되 고 있 다. 구조화체 계분석 이 나 그것 의 변종방법 들을 
리용할수 있는 좋은 기회가 있다. 그러나 다른 흘륭한 준형식적기법들도 많다. 실례로 쏘 
프트웨 어 명세작성 과 설계 에 대 한 각이한 국제 연구토론회 회 보들을 보시 오. 서 술공간의 제 
약으로 인하여 여기 에서 제시하는 모든 방법들은 몇 가지 잘 알려 진 기 법들에 대 한 간단 
한 서술에 지 나지 않는다. 

PSL / PSA[Teichroew and Heshey , 197기은 정 보처 리제 품을 명 시 하기 위한 를퓨터 지 원기 
법이다. 이 이름은 이 기법의 두가지 구성요소로부터 유래되였다. 즉 제품을 서술하는데 
리 용된 문제 서 술언어 (/woWem statement language .， PSL ) 와 PSL 서술을 자료기지 에 입 력 하고 
요구에 대 한 보고서 를 생 성 하는 문제 서 술분석 기 (praWem statement analyzer ; PSA ) 로부터 
유래 되 였 다. PSL / PSA 는 광범히 리용되 고 있는데 특히 제 품을 문서 화하는데 서 많이 리용 
된 다. 

SADT [ Ross , 1985] 는 두개의 호상관련된 요소들로 구성 되여 있 다. 즉 구조분석 (대 rac / wra / 
analysis' SA ) 이 라고 명명 한 통 및 화살표 (6 ox - ancf - amw ) 도식 언어 와 설계기 법(土打 gw technique; 
DT ) 로부터 SADT 로 명명되였다. 게인과 사르센의 기법을 보다 크게 확장하는데서 계단식 
세련방법이 SADT 를 밑받침하고 있다. 밀러의 법칙을 준수하는데 의식적인 노력을 기울 
였다. 토스가 제시한바와 같이 《무엇인가 말할만한 가치가 있는것에 대하여 말할만한 
가치가 있는것은 6개 또는 그보다 적은 단락으로 표현되여 야 한다.》 [ Ross , 1985]. SADT 
는 광범한 종류의 제 품들 특히 복잡하고 규모가 큰 제 품들을 명 시하는데 성 과적 으로 리 
용되 였다. 다른 많은 류사한 준형식적 기법들과 마찬가지 로 SADT 의 실시 간체 계 에 대 한 
응용성은 그리 명확치 않다. 

다른 한편 S^EM{software requirements engineering method', " shrem ” 이 라고 발음한 
다.)은 명백히 어떤 작용이 출현하지 않는 조건들을 명시하기 위하여 설계되였다 
[ Alford , 1985]. 이 리 유로 하여 SREM 은 실 시 간체 계 를 명 시 하는데 특별 히 쓸모 있 었 
으며 분산체 계들에 로 확장되 였 다. SREM 은 많은 요소들로 이 루어 진 다. RSL 은 하나의 
명세작성언어 이 다. REVS 는 명세작성 과 관련된 여 러 가지 과제 들을 수행하는 도구들의 
모임인데 이러한 과제들을 RSL 명세서로 어떤 자동화된 자료기지로 변환하는것, 자료 
흐름의 일 치 성 을 자동적 으로 검 사하는것(거 기 에 어 떤 값이 할당되 기전에 그 어 떤 자 
료항목도 리용되 지 않는다는것 을 확인하는것)，명세서 들이 정 확성 을 확인하는데 리용 
될수 있는 모의기 를 명세 서 로부터 발생하는것 등이 다. 이 밖에 SREM 은 하나의 설계기 
법 즉 분산공퓨터 설계 체계 DCDS(distributed computing design 섟생/ em ) 를 가지고 있 다. 

SREM 의 능력은 전체 기법들의 기초를 이루고 있는 모형에서 흘러 나오는데 그것이 
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바로 11.6 에 서 설 명 하는 유한상태 기 계 FSM{ftnite state machine )^] 4- SREM 의 초석 으로 
되고 있는 이 형식적모형의 결과로써 앞에서 언급한 일관성검사를 진행하며 개별적요소 
들의 성능이 주어 졌을 때 제품에 대한 성능제약이 총체적으로 만족될수 있다는것을 검 
증하는것이 가능할수 있 다. SREM 은 미 공군에서 두가지 C \ command , control , commu 
nication , and intelligence )^ 계 들을 명 시 하는데 리 용되 였 다 [ Scheffer , Stone , and Rzepka , 
1985]. SREM 이 명 세작성단계 에 서 많이 리용된 다고 증명 되 였 다고 할지 라도 생 명 주기 의 
뒤 단계 에 서 채 용되 는 REVS 가 덜 쓸모 있 다고 고찰된것 같다. 

11.5. 실처卜관련모령화 

구조화체계분석에서 중점은 만들어 질 제품의 자료가 아니라 그 작용들이다. 명백히 
제품의 자료도 모형 화되지 만 자료는 작용에 비 하여 2차적 이 다. 이와는 대 비적 으로 실체- 
관련 모형 화 ( e / jft ’ 沙-中 modeling ', ERM ) 는 제 품을 명 시 하기 위 한 준형 식 적 인 자료지 
향기법 이 다. 제품의 응용령역 에서 중점은 자료에 있다. 물론 작용들이 자료에 접근하는것 
이 필요하며 자료기지는 접근시간을 최소로 하는것과 같은 방식으로 조직되여 야 한다. 
그러나 자료에 대하여 수행된 작용들은 그리 중요하지 않다. 

실 체 -관련모형화는 새 로운 기 술이 아니 다. 즉 그것 은 1976년 이 래 광범히 리용되 여 
왔다 [ Chen , 1976]. 현재 실 체 -관련모형 화는 새 롭게 부활되 고 있 다. 왜 냐하면 그것 이 제 12 
장에서 자세 히 서술되는 객체지향분석의 한가지 요소로 되 기때 문이 다. 

한가지 실체-관련도가 그림 11-9 에 제시되는데 그것은 저자，자서전，독자들사이의 
관계를 모형화하고 있다. 여 기 에는 세개의 실체 : 저자 , 자서전 , 독자가 있다. 제 일 웃관계 쓰 
기는 저자가 자서전을 읽는다는것을 반영하고 있다. 이것은 1대 n ( o « e - to - ma 때)관계이다. 
왜 냐하면 한명 의 저 자가 하나이상의 자서 전을 읽 을수 있기때 문이 다. 이것은 저 자다음의 
1과 자서전 다음의 n 으로서 반영된다. 실체-관련도에서는 또한 자서전과 독자사이의 두 
개의 관계를 보여 주고 있다. 


1 ᅨ 

4 j 

소 

h 

느 기 


n 

1 자 

서 전 

n 

읽기 

h 

n 

소유 

卜 


자 1 


그림 11-9. 간단한 실체-관련도 


347 




이 두개 가 다 1대 n 관계 이 다. 여 기서 왼쪽의 관계 는 한명의 독자가 여 러개의 자서전 
을 읽 었을수 있다는 사실을 모형화하고 있다. 류사하게 오른쪽에 보여 준마와 같이 한명 
의 독자가 여 러개의 자서전을 가질수 있다. 

한명의 독자가 하나의 자서전을 소유하지 않고 읽을수 있으며 또 한명의 독자가 자 
서 전은 사지 만 그것 을 읽 지 않을수 있기때 문에 두개 의 분리 된 관계 들을 보여 준다. 다음 
의 실례 는 공급자의 령역과 그들이 공급하는 부분품들로부터 얻 어 진다. 그림 11-10 은 
부분품들과 공급자들사이의 n 대 n 관계를 보여 주고 있다. 즉 한명의 공급자는 여러개의 
부분품을 공급하며 거꾸로 하나의 특수한 부분품이 여러 공급자들로부터 얻어 질수 있다. 


공급자 



공급한다 


| 부분품 | 

그 1 0 11-10. n 대 n (many-to-many) 실체-관련도 

이 n 대 n 관계 는 실 체(공급자)의 밑 에 쓴 이과 실 체(부분품)우에 쓴 n 에 의하여 반영 
된 다. 

또한 보다 복잡한 관계들도 있을수 있다. 실례로 그림 11-11 에 보여 준바와 같이 이 
번에는 하나의 부분품이 많은 요소 부분품들로써 이루어 지는것처럼 보일수 있다. 



그림 11-11. 보다 복잡한 실체-관련도 


또한 n 대 n 대 n 관계 가 가능하다. 그림 에서 보여 준 3개의 실체 공급자 , 부분품，프로젝 
트를 고찰하자. 

하나의 특수한 부분품이 해당 프로젝트에 따라 여러 공급자들로부터 공급될수 있다. 
또한 하나의 특수한 프로젝트에 대 하여 공급되는 여 러 가지 부분품들은 서로 다른 공급자 
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들로부터 공급될 수도 있 다. n 대 n 대 n 관계 는 이 와 같은 상황을 정 확하게 모형 화하는데 
필요하다. 

실체-관련모형화는 다음장에서 더 론의되는데 거기에서는 객체지향분석과 또 하나의 
준형식적기법을 서술한다. 이 장의 다음화제는 형식적기법들이다. 다음 4개 절의 기본문 
제는 형식적기법을 채용하는것이 준 형식적 또는 비형식적기법으로 달성가능한것보다 더 
정 확하게 명세서를 작성할수 있다는것 이 다. 그러 나 형 식적기 법의 리용은 일반적 으로 오 
랜 숙련을 필요로 하며 형식적기법을 리용하는 쏘프트웨어공학자들에게는 련관된 수학적 
지식을 소유하는것 이 필요하다. 다음절에서 최소한도의 수학적내용을 서술하였다. 더우기 
가능한 개소마다 수학적공식 화를 동등한 내 용의 비 형 식적표현에 선행하여 서술한다. 그 
러 나 11.6 부터 11.9 까지의 준위는 이 책의 나머지부분들의 준위보다 더 높다. 

11.6. 유한상태기계 

영 국의 방송대 학(公 pen t/n/vera 沙)의 M202 개 발림 이 처 음으로 형 식 화한 다음과 같은 
실례 를 고찰하자 [Brady, 197刀. 어 떤 안전기 는 1, 2, 3으로 표식 된 3개 의 위 치 중의 하나에 
놓일 수 있 는 하나의 열 쇠조합을 가지 고 있다. 번 호판은 왼쪽으로부터 오른쪽으로 돌아 
갈수 있다 (L or R). 결국 임의의 시각에 6개의 번호판이동이 가능하다. 즉 1L, 1R, 2L, 
2R, 3L, 3R 이다. 안전기에 대한 열쇠조합은 1L, 3R, 2L 이라고 하자. 즉 임의의 다른 번호 
판이동은 경 고를 발생하게 할것 이 다. 이 상황을 그림 11-12 에서 보여 주고 있다. 여기 에 
는 하나의 초기상태 안전보호 (Safe Locked) 가 있다. 만일 입력이 1L 이라면 다음상태는 A 
이 다. 그러 나 만일 임의의 다른 번호판이동 이를테 면 1R 와 3L 이 발생하면 그다음 상태 는 
두개의 최종상태중의 하나인 경고음 (Sound Alarm) 으로 된다. 


안전보호 

그 

국와 

안전비보호 

기타 다른 \ 
눈금판으로 
이동 

기타 다른 
눈금판으로 
\이동 

/ 

; 기타 다른 

7 눈금판으로 
이동 

11초기상래 


r ^ - 

신 


1 I 마감상태 


그림 11-12. 결합안전의 유한상태기계표현 


만일 정확한 열쇠조합이 선택되면 이 행렬은 안전보호 (Safe Locked) 로부터 A, B, 안전 
비보호 (Safe Unlocked) (최 종상태)로 된다. 

그림 11-12 는 유한상태기계의 상태 이 행도 (Wa/e transition diagram : STD) 를 보여 주고 
있 다. STD 를 그라프적 으로 표현하는것 은 필 요 없 다. 이 와 동일한 정 보를 그림 11-13 에 서 
표현적 인 형식으로 보여 주었다. 표에서는 두개의 최종상태가 아닌 매 상태에 관하여 다 
음상태에로의 이행을 번호판이 움직이는 방법에 기초하여 지적하고 있다. 
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그림 11-13. 유한상태기계를 위한 상태이동표 


유한상태기계는 5개의 부분들로 이루어 진다. 즉 상태들의 모임 J , 입력모임 K , 현재 
의상태와 현재의 입력이 주어 진 조건에서 다음상태를 규정하는 이행함수 T , 초기상태 
S 그리 고 최 종상태모임 표로 이 루어 진다. 안전기 에 대 한 열쇠 조합의 경 우에 그 모임 들은 
각각 다음과 같다. 

상태모임 조는 {안전보호, A , B , 안전비보호，경고음} 이 다. 

입 력모임 K 는 {1 L ; 1 R , 2 L , 2 R , 3 L , 3 R } 이 다. 

이행함수 고는 그림 11-13 의 표형식으로 표현된다. 

초기 상태 S 는 안전보호이 다. 

최 종상태모임 표는 {안전비보호, 경고음} 이 다. 

보다 형 식적 인 용어로 표시하면 유한상태 기계는 다음조건을 가지는 5원묶음 ( J , K . T , 
S , F ) 이 다. 


조는 유한한 비 지 않은 상태모임 이 다. 

도는 유한한 비 지 않은 입 력모임 이 다. 

T 는 이 행 함수라고 부르는 ( J 〜 F ) XK 로부터 J 에 토의 넘 기 기 이 다. 

SeJ 는 초기상태 이 다. 

표는 최종상태들의 모임 FGJ 이 다. 

유한상태 기계방법은 콤퓨터응용에서 광범히 리용되 고 있다. 실례 로 매 개의 차림 표구 
동사용자대 면부는 유한상태기계의 한가지 실현이 다. 어떤 차림표의 현시는 하나의 상태 
에 대 응하며 건반에 서 하나의 건을 입 력하거 나 마우스로 하나의 아이 콘을 선택하는것 은 
제품을 다른 상태 에 로 이 행하도록 하는 사건과 등가이 다. 실례 로 주차림표가 화면에 나 
타났을 때 V 를 입 력하면 현재 의 자료모임 에 대 하여 크기분석 을 진행하게 할수도 있다. 
그다음 새 차림 표가 출현하며 사용자는 G , P , 또는 묘를 입 력 할수 있 다. G 를 선택하면 계 
산결 과를 그라프로 작성하게 하며 묘를 선택하면 그것 을 인쇄하며 , 묘는 주차림 표에 로 돌 
아 오게 한다. 매 이행은 다음과 같은 형식을 가진다. 
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current state [ menu ] and event [option selected ] => next state (11-1) 

어 떤 제 품을 명 시 하기 위하여 FSM 을 확장하는 유용한 한가지 방법 은 선행한 5원묶 
음에 여섯번째 요소 즉 술어모임 모를 추가하는것 이 다. 모임 근에서 매 개의 술어는 제품의 
대역상태 구의 값이다 [ Kampen , 198刀. 

보다 형식적으로 이행함수 T 는 (J 〜 F)XKXP 로부터 J 에로의 넘기기이다. 이행규칙은 
다음과 갈은 형식을 가진다. 


current state and event and predicate => next state (11.2) 

유한상태기계는 상태와 상태들사이의 이행에 의하여 모형화될수 있는 제품을 명시하 
기위한 강력한 형식화방법이다. 이러한 형식화가 실천에서 어떻게 리용되는가를 보기 
위하여 이 방법을 이제 이른바 승강기문제의 변화된 형식에 적용한다. 승강기문제에 대 
한 배경정보에 관해서는 다음의 《알고 싶은 문제》를 보시오. 


알고 싶용 @제 

승강기문제는 사실상 쏘프트웨어공학의 고전적인 문제이다. 그것은 1968년에 I •판된 
돈 크나스의 력사적인 저서의 제 1권 The Art of Computer Programming[Knuth, 19 i 매에서 
처음으로 제시되 였다. 이 문제는 캘리포니 아공학연구소의 수학청사에 있늘'_단독슴 3•기에 
기초를 두고 있다. 이 실례는 공상적인 프로그람언어 MIX 에서 협동부분프로그람; ■을 례 
중하는데 리 용되 였 다. 

1980년대 중엽 까지 승강기문제 는 n 개 의 승강기 에 로 일 반화되 였 다. 게 다가 3. 풀이 의 
특수한 성질들이 중명되여야 하였다. 실례로 승강기가 결국 유한시간내에 도달할것 사라는 
문제 이 다. 승강기 문제 는 형 식적 명세작성언어 분야에 종사하는 연구자들을 위한 문ᄎ 로 되 
였고 모든 제 안된 형 식적명세작성언어 들은 승강기문제 에 관하여 수행되 여 야 하였^ 

이 문제는 ‘1986년 쏘프트웨어 명세작성 및 설계 에 관한 제4차 국제 연구회 ！;] VSSD , 
1986] 론문집의 ACM SIGSOFT Software 松 八 feteH 서 더 폭 넓게 제시되 S 다. 승 

강기 문제는 1987년 5월 캘리포니 아의 몬테 레 이 ( Monterey ) 에서 진행된 회의 에 대 한 비 안에 
서 연구자들이 리용한 다섯가지문제들중의 하나이다. 이 문제는 론문집에서 STi -IDEC 
[영 국의 스테 베 나쥐 ( Stevenage ) 에 있는 표준원격 및 유선통신국]의 엔 다비 스에 의 I 여 승 
강기문제(폐……노비로 명명되 였다. 그때 로부터 이 문제는 더욱더 두드러지 게 되 장으며 
쏘프트공학에 서 형 식 적 명 세 작성 언 어 를 제 외 한 여 러 가지 확장된 기 법 들을 보여 주: •데 일 
반적 으로 리 용되 였 다. 이 책 에서 는 이 방법 을 매 기 법 들을 례증하기 위하여 리 용한ᄐ . 왜 냐 
하면 곧 알수 있는 바와 같이 이 문제가 보기처럼 그리 간단하지 않기때문이다. 


11. 6- 1 • 승강기문제: 유한상태기계 

이 문제 는 다음과 같은 제 약에 따라 m 층사이 에 서 n 개 의 승강기 를 움직 이는데 필 요 
한 론리와 관련된 문제이다. 
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1. 매 승강기는 이재의 단추모임을 가지고 있는데 매 층에 하나의 단추가 대응한다. 
단추들은 불이 켜지며 승강기가 대응하는 층을 찾아 가게 한다. 승강기가 대응하 
는 층을 찾아 갔을 때 단추의 불은 꺼진다. 

2. 1층과 마지막층을 제외 하고 매 층은 두개의 단추를 가진다. 하나의 단추는 승강 
기 가 올라 갈것 을 요청하며 다른 하나는 승강기 가 내 려 갈것 을 요청하는 단추이 
다. 이 단추들을 누르면 불이 켜진다. 승강기가 해당한 층을 찾아 간 다음 희망하 
는 방향으로 움직일 때 불이 꺼진다. 

3. 승강기에 아무런 요청도 없을 때 승강기는 문을 닫은채로 현재의 층에 머물러 있다. 

이 제 제 품은 확장된 유한상태 기계 [ Kampen , 198 기를 리용하여 명 시 된다고 하자. 그러 
면 이 문제 에서는 두개의 단추모임 이 존재한다. 매 n 개의 승강기 에 이재의 단추모임 이 있 
다. 매 단추가 매 층에 대 응한다. 이 nXm 개의 단추들은 승강기안에 있기때 문에 그것들 
은 승강기 단추 ( e/evator boons ') 로 간주된 다. 그리 고 매 층에 두개 의 단추가 있는데 하나 
는 승강기상승을 요청하는것 이고 하나는 승강기하강을 요청하는것 이 다. 이 단추들을 층 
단추 (/7 oor buttons ) 로~ 간주한다. 

한개 의 승강기단추에 대 한 상태이 행 도를 그림 11-14 에 보여 주었 다. 



그림 11-14. 승강기 단추를 위 한 STD [ Kampen , 1987]. (©1987 IEEE .) 

EB ( e , 句는 층 f 를 요청하기 위하여 눌러 진 승강기 e 안에 있는 단추를 의미한다고 
하자. EGB ( e , 句는 두가지 상태 즉 단추에 불이 온 상태든가 단추에 불이 꺼진 상태에 있 
을수 있다. 보다 정확하게 상태는 다음과 갈다. 

EBON ( e , f ) : Elevator Button ( e , f ) ON 

EBON ( e , f ) : Elevator Button ( e , f ) OFF (11.3) 

만일 단추가 on 상태에 있고 승강기가 층 균에 이르면 단추는 o 伴상태로 설정된다. 반 
대 로 단추가 o 伴상태 에 있고 눌러 져 있으면 단추는 on 상태 로 된다. 

따라서 다음의 두개의 사건이 일어 난다. 

EBP ( e , f ) : Elevator Button ( e , f ) Pressed 

EAF ( e , f ) : Elevator e Arrives at Floor f (11.4) 

이 사건들과 상태 들을 련결 하는 상태 이행규칙 들을 정 의 하기 위하여 술어 V ( e , 句가 
필요하다(하나의 술어는 참 또는 거짓으로 되는 어떤 조건이다.). 
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V ( e , f ) : Elevator e is Visiting (stopped at ) floor f (11.5) 

형 식 적 이 행 규칙 들이 서 술된 다. 만일 승강기 단추 ( e , f ) 가 꺼 져 있고(현재 상태 ) 승강기 단 
추 ( e , 句는 눌러 지며(사건) 승강기 e 는 층 f 를 찾아 가지 못하고 있다(술어)면 이행규칙 (1 
1.2) 의 형식으로서 이것은 다음과 같이 표현된다. 

EBOFF ( e , f ) and EBP ( e , f ) and not V ( e , f ) EBON ( e , f ) (11 石) 

만일 승강기가 현재 층 f 를 찾아 가고 있다면 아무 사건도 일어 나지 않는다. 캄펜 
의 형식화에서 실지로 이행을 일으키지 않는 사건들이 생길수 있다. 그러나 만일 그러한 
사건들이 생긴다면 그것들은 무시된다. 

거꾸로 만일 승강기가 층 f 에 도달하고 단추가 켜져 있다면 그것은 꺼진다. 이것은 
다음과 같이 표현된다. 

EBON ( e , f ) and EAF ( e , f ) 각 EBOFF ( e , f ) (11.7) 

이제 는 층단추들을 고찰하자. FB ( d , 회는 승강기 가 방향 이로 움직 일것 을 요청하는 층 
예 서 의 단추를 의 미한다. 

층 단추 FB ( d , 句를 위한 STD 는 그림 11-15 에 보여 주었 다. 



FBP(d, f) 


FB0FF(e, f) 

EAF(l..n, f) 

FBON(e, f) 


그림 11-15. 층 단추를 위 한 STD [Kampen, 1987]. (01987 IEEE.) 


보다 정 확하게 이 상태들은 다음과 같다. 

FB 0 N ( d , f ) : Floor Button ( d , f ) ON 

FBOFF ( d , f ) : Floor Button ( d , f ) OFF ( 1L8 ) 

만일 어떤 단추가 켜져 있고 승강기가 정 확한 방향에 로 움직 여 층 f 에 도착한다면 
그 단추는 꺼진다. 

거꾸로 만일 그 단추가 꺼져 있고 그것을 누른다면 그 단추는 켜지게 된다. 또한 다 
음의 두개의 사건이 일어 난다. 

EBP ( d , f ): Floor Button ( d , f ) Pressed 

EAF ( l .. n , f ): Elevator 1 or … or n Arrives at Floor (11.9) 

l .. n 을 리용하여 분리 를 표시 하자. 이 절 전반에 서 P ( al , n , 비와 갈은 식 은 다음의 
식 을 의 미한다. 

P ( a , 1, b ) or P ( a , 2, b ) or … or P ( a , n , b ) (11.10) 
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이 사건들과 상태 들을 련결 하는 상태 이 행 규칙 들을 정 의 하기 위 하여 역 시 술어 가 필 
요하다. 이 경우에 그것은 S ( d , e , 句를 표시하는데 다음과 같이 정의된다. 

S ( d , e , f ): 승강기 e 는 층 f 를 찾아 가고 있으며 이동하려는 방향은 

우로 ( d = U ) 혹은 아래로 ( d = D ) 이 거 나 그 어 떤 요청 도 (11.11) 

( d = N ) 를 만족시키지 못한다. 

이 술어 는 사실상 하나의 상태 이 다. 사실 이 형 식 화는 사건과 상태모두를 술어 로서 
취급할수 있게 한다. 

그러면 S ( d , e , f ) 를 리용하여 형식적이행규칙들을 다음과 같이 쓸수 있다. 

FBOFF ( d , f ) and FBP ( d , f ) and not S ( d , l .. n , f ) 

각 FBON ( d , f ) (11.12) 

FBON ( d , 0 and EAF ( l .. n , f ) and S 後， l .. n , f ) 

각 FBOFF ( d , f ), d = U or D 

즉 만일 방향 d 에 로의 이동에 대 하여 층 的ᅵ 있는 층단추가 꺼져 있고 그 단추가 눌 
러 져 있으며 방향 d 로의 이동에 대하여 그 어떤 승강기도 현재 층 f 로 찾아 가고 있지 
않다면 그 층 단추는 켜진다. 거꾸로 만일 그 단추가 켜져 있고 적어도 한대의 승강기가 
층 fi 도착하고 승강기 는 방향 d 로 움직 이 려 한다면 그 단추는 꺼 진다. 식 S ( d , l .. n , f ) 
와 EAF ( l .. n , 句에 서 표식 l .. n 은 식 (11.10) 에 서 정 의 되 였 다. 정 의 (11.5) 의 술어 V ( e , 句는 
S ( d , e , 句에 의하여 다음과 같이 정 의 될 수 있 다. 

V ( e , f ) = S ( U , e , f ) or S ( D , e , f ) or S ( N , e , f ) (11.13) 

승강기단추와 층단추들의 상태는 곧바로 정의되 였다. 

승강기에로 돌아 가 생각해 보면 복잡한 문제들이 생겨 난다. 승강기의 상태는 본질 
상 많은 요소상태들로 이루어 진다. 캄펜은 승강기의 속도감속 및 정지，문열기，설정시 
간내에서의 문열어놓기, 시간초과후의 문닫기와 같은 여러가지 상태들을 구별하고 있다 
[ Kampen , 1987]. 그는 승강기 조종기 (승강기 의 이 동을 지 휘 하는 기 구)가 S ( d , e , 사와 갈은 
상태 에 서 시 작하며 그다음 조종기 는 승강기 가 부분상태 들을 통해 움직 인 다는 론리적 인 
가정 을 하고 있 다. 세 가지 승강기상태 들을 정 의할수 있 다. 그 하나인 S ( d , e , f ) 는 정 의 
(11.11) 에서 정의되였는데 여기에서는 완전한 정의를 준다. 

M ( d , e , f ): Elevator e is Moving in direction d(floor f is next ) 

S ( d , e , f ): Elevator e is Stopped ( d - bound ) at floor f (11.14) 

W ( e , f ): Elevator e is Waiting at floor f (door closed ) 

이 상태들은 그림 1 卜 16 에 보여 주었다. 세개의 정지상태 S ( U , e , f ), S ( N , e , f ) 와 S ( D , 
e , f ) 는 상태 도를 간단화하기 위하여 하나의 보다 큰 상태 로 묶어 졌 다. 

상태이 행을 유발시 키는 사건들은 DC ( e , f ), ST ( e , f ), RL 이다. DC ( e , 句는 층 빼서 승 
강기 e 의 문을 닫는것 이 다. ST ( e , f ) 는 승강기 가 층 f 에 가까와 갈 때 승강기수감기 가 유 
발되 여 승강기 조종기 가 승강기 를 그 층에 서 멈 추어 야 하는가 아닌 가를 결 정하여 야 하는 
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고 있다. 두번째와 세번째 규착은 승강기가 내려 가려고 하는 경우나 승강기에 대한 아 
무런 요청도 없는 경우에 대응한다. 

이 규칙형식들은 복잡한 제 품들을 명시 하는데서의 유한상태기계들의 능력을 반영 하 
고 있다. 

해당 제품이 무엇을 하기 위하여 준수해야 할 복잡한 사전조건들의 모임을 렬거하고 
그다음 그 제품이 그것을 수행한후에 준비해야 할 모든 조건들을 렬거하는것 대신에 명 
세서는 다음과 갈은 간단한 형식을 취하게 된다. 


current state and event and predicate 과 next state 

이러한 류형의 명세서는 작성하기 쉽고 검증하기 쉬우며 설계 및 코드로 변환하기 
쉽다. 사실상 유한상태기계명세서를 직접 원천코드로 번역하는 CASE 도구를 구축하는것 
은 간단하다. 유지정 비는 유한상태기계의 재 연으로서 달성된다. 즉 만일 새 로운 상태 나 
사건들이 필요하다면 명세 서 가 변경되 며 새 로운 제 품판본이 직 접 새 로운 명세 서 로부터 
만들어 지게 된다. 

FSM 방법은 11.3.1 에서 제시한 게인과 사르센의 도형적기법보다도 더 명백한데 거의 
그들의 방법 만큼 리해 하기 쉽다. 

FSM 방법은 한가지 결함을 가지고 있는데 그것은 대규모체계들에서 3원묶음 ( state , 
event , predicate ) 의 개수가 급격히 증가한다는것이다. 또한 게인과 사르센의 기법과 마찬 
가지로 캄펜의 형식화에서 시 간제 약은 취급하지 않고 있다. 이 문제들은 FSM 의 확장인 
상태 도표를 리 용하여 해 결 할수 있 다 [Harel et al ., 1990]. 상태 도표는 매 우 강력 한 수단이 
며 그것 은 CASE 작업 프로그람인 Rhapsody 에 의 하여 지 원되 고 있 다. 이 방법 은 대 규모실 
시 간체 계 들에 성 공적 으로 리 용되 였 다. 

시 간문제 를 처 리 할수 있는 다른 하나의 기 법 은 페 트리 망이 다. 

11.7. 페트리망 

병행체계를 명시하는데서 제기되는 중요한 난점은 시간문제에 대처하는것이다. 이 
난점은 동기화문제, 경쟁조건，교착상태와 같은 여러가지 각이한 방식으로 나타난다 
[Silberschatz and Galvin , 1998]. 시간문제는 비록 서투른 설계나 오유실현의 결과로서 생겨 
날수 있다고 하여도 이와 같은 설계 나 실현은 흔히 서투른 명세작성의 결과이 다. 만일 명 
세서가 적당하게 작성되지 않으면 대응하는 설계와 실현이 부적당하게 될수 있는 매우 
실질적 인 위험성 이 존재하게 된다. 체 계를 잠재적 인 시 간문제 와 함께 명시 하기 위한 한 
가지 강력한 기 법은 페트리망이 다. 이 방법 의 또 하나의 우월성 은 그것 이 설계 에서도 역 
시 리용될 수 있 다는것 이 다. 

페트리망은 칼 아담 페트리 에 의하여 발명되 였 다 [P 的 i , 1962]. 원 래 페트리 는 자동체 
리 론에 흥미 를 가지 고 있 었다. 페트리 망은 콤퓨터 과학에 서 광범한 응용가능성 을 가지 고 
있는데 성 능평 가，조작체 계 , 쏘프트웨 어 과학과 같은 분야들에 서 리용되 고 있 다. 특히 페 
트리망은 동시 에 서 로 관계 되 는 작용들을 서 술하는데서 유용하다는것 이 증명되 였 다. 그 
러나 명세작성에서의 페트리망리용을 보여 주기에 앞서 그에 익숙되여 있지 않을수도 있 
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는 독자들을 위 하여 페 트리 망에 대 하여 간단히 소개 한다. 

페트리 망은 4개 부분 즉 마디점모임 P , 이 행모임 T , 하나의 입 력 함수 I , 하나의 출력 
함수 0로 구성된다. 그림 11-17 에 보여 준 페트리망을 고찰하자. 



마디점모임 요는 { Pl , P 2, P3, P4} 이 다. 

이 행모임 T 는 { t ,, 미 이 다. 

마디점으로부터 이행에로 가는 화살표들로 표시된 두개의 이행에 대한 입력함수들은 
다음과 갈다. 

i ( ti ) = { P 2, p 4 
1( 切 = { p 2 } 

이행들로부터 마디점에로 가는 화살표들로 표시된 두개의 이행에 대한 출력함수들은 
다음과 같다. 


0( ti |. ^ { pi } 

0( 切 = { p 3 , P3 } 

P 3 이 중복되 였 다는것 을 주목하라. 즉 t 2 로부터 P 3 에 로 가는 두개 의 화살표가 있다. 
보다 형 식적 으로 [ Peterson , 1981] 하나의 페트리망은 다음과 같은 4원묶음 C =( P , T , I , 
0) 이다. 

P = { pi , p2 , • pn } 는 마디점 ( p / ace ) 들의 유한모임 이 다. Jt _0 
T = { t b t 2 , •••, t m } 는 이 행 (_ 패的 o «) 들의 유한모임 이 다. mWi 요와 T 는 분리되 여 
있 다. 

I:T ᅳ는 입 력 함수이 며 이 행 들로부터 마디 점 들의 다중모임 ( teg ) 에 토의 넘 기 기 이 다. 
0 :T ᅳ P °° 은 출력함수이며 이행들로부터 마디점의 다중모임에로의 넘기기이다(다 
중모임(뇨 g or multiset) 은 한 요소의 다중실례들을 허용하는 모임의 일반화 
이 다.)' 

페트리 망을 표식하는것 은 그 페트리 망에 대 하여 표식기 호들을 할당하는것 이 다. 그림 
11-18 은 4개의 표식기호를 포함하고 있다. 즉 미에 1개, 야에 2개, p 3 에는 없고 마에 
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는 1개 이다. 이 표식 붙이 기 는 벡 토르 (1, 2, 0, 1) 로 표시할수 있 다. 이 행 다은 p 2 와 P 4 에 표 
식 기호가 있기때문에 작용된다(발화될 준비가 되 여 있다.). 일반적 으로 하나의 이행은 만 
일 그 이행의 매개 입력마디점들이 그 마디점으로부터 그 이행에로 가는 호의 개수만한 
표식기 호들을 가진다면 작용된 다. 만일 다이 발화되 여 야 한다면 p 2 로부터 하나의 표식기 호 
를 제 거 하고 P 4 로부터 하나의 표식기 호를 제 거하며 하나의 새 로운 표식기 호가 Pi 에 위 치 
하게 된다. 표식기호들의 개수는 보존되지 않는다. 즉 두개의 표식기호가 제거되였지만 
한개 만이 Pi 에 넣 어 진다. 그림 11-18 에 서 이 행 t 2 또한 작용된 다. 왜 냐하면 P2 에 표식기 
호들이 있기때 문이 다. 만일 t 2 이 발화되 여 야 한다면 하나의 표식기 호가 P 2 로부터 제 거될 
것이며 두개의 새로운 표식기호들이 야에 넣어 진다. 


P 2 



페 트리 망은 비 결 정 적 이 다. 즉 만일 하나이 상의 이 행 들이 발화될 수 있 다면 그것 들 
가운데서 임의의것이 발화될수 있다. 그림 11-18 은 표식 (1，2, 0, 1) 을 가지고 있다. 
즉 다과 t 2 은 모두 작용된다. 다이 발화된다고 가정하자. 결과적인 표식 (2, 1, 0, 0) 은 그 
림 11-19 에 보여 주는데 여기에서는 t 2 만이 작용된다. 그것이 발화되면 작용되는 표식 
기 호는 P 2 에 서 제 거 되 고 두개 의 새 로운 표식 기 호가 P 3 에 놓인 다. 그러 면 표식 은 그림 
11-20 에 보여 준것 처 럼 (2, 0, 2, 0) 으로 된다. 
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그림 11-20. 이행 t 2 가 발화한 다음 그림 11-18 의 페트리망 

보다 형 식적 으로 [ Peterson , 1981] 하나의 페트리망 C =( P , T , 0) 의 하나의 표식 보은 마 
디점모임 P 로부터 부아닌 옹근수들의 모임에로의 넘기기이다. 즉 
M :P — {0, 1，2, •••} 

그러 면 표식 된 페트리 망은 하나의 5원묶음 ( P ， T , I , O , M ) 으로 된 다. 

페트리망에 대한 하나의 중요 한 확장은 하나의 억제 호(切 / n ’ toor ) 이다. 그림 11-21 에서 
억 제호는 화살머 리 가 아니 라 작은 동그라미 로 표식 된 다. 



그림 11-21. 억제호를 가진 페트리망 


이 행 산은 p 3 에 는 하나의 표식기 호가 있지 만 마에 는 없기 때 문에 작용된다. 일 반적으 
로 어떤 이행은 만일 그 이행의 모든(표준) 입력호들에 적어도 하나의 표식기호가 놓이 
고 그 이행의 어떤 억제호들에도 표식기호가 놓이지 않는다면 작용된다. 이러한 확장은 
11 .6. 1 에 제 시 된 승강기 문제 에 대 한 페 트 리 망명 세 작성 에 서 리 용될 것 이 다 [ Guha , Lang , 

Bassionui , 198 刀. 

11. 7. 1 . 승강기문제 : 페트리망 

n 개 의 승강기 체 계 가 m 층건물에 설 치 되 게 된 다는것 을 상기 하자. 이 에 대 한 페 트리 망 
명 세 작성 에 서 건물의 매 층은 하나의 마디 점 F f , 으로 표시 되 며 페 트리 망에 서 하 


359 



나의 승강기는 표식 기호로 표현된다. 라 의 하나의 표식 기호는 한개의 승강기 가 층 에 
있다는것을 의미한다. 

첫번째 제약 매 승강기 는 m 개 의 층들로 이 루어 진 모임 을 가지 는데 매층에 하나의 
단추가 대응된다. 단추들을 누르면 불이 켜지며 승강기가 대응하는 층을 찾아 가게 한다. 
승강기가 대응하는 층을 찾아 가면 단추의 불은 꺼진다. 

이 상황을 명세서에 넣기 위하여서는 추가적인 마디점들이 필요하다. 층 f 에 대한 
승강기 단추는 페 트리 망에 서 마디 점 EB f , 으로 표현된 다. 보다 정 확히 는 n 개 의 승 

강기가 있기때문에 마디점은 EB f , e , l&f 으 m , 1 호 di 으로 표현되여 야 하며 승강기를 나 
타내 는 첨 수 e 는 생 략된 다. 

EB f 안의 하나의 표식기 호는 층 f 에 대 한 승강기단추가 켜 졌 다는것 을 의 미한다. 단추 
는 그 단추가 처음 눌러울 때만 켜지고 련이은 단추누르기는 무시되기때문에 이것을 그 
림 11-22 에 보여 준바와 같이 페트리망을 리용하여 명 시한다. 먼저 단추 EB f 가 불이 켜 
지 지 않았다고 가정 하자. 따라서 마디점 안에 는 아무런 표식기 호도 없으며 억 제호가 존재 
하기때문에 이행 EB f pressed 가 작용된다. 이제 그 단추를 누른다. 그 이행이 발화되며 그 
림 11-22 에 보여 준것 처 럼 EB f 에 새 로운 표식기 호가 놓인다. 이 제 단추를 아무리 많이 
눌러도 억제호와 표식기 호존재의 조합은 이 행 EB f pressed 가 작용될수 없다는것을 의미한 
다. 그러 므로 하나이상의 표식기 호는 EB f 안에 놓일 수 없 다. 승강기 가 층 g 로부터 층 f 로 
움직 인다고 가정 하자. 

action F f 

—o 


그림 11-22. 승강기단추의 폐 트리 망표현 
[Guha, Lang, and Bassiouni, 1987], (©1987 IEEE.) 

승강기 는 층 용에 있기 때 문에 그림 11-22 에 보여 준것 처 럼 마디점 Fg 에 하나의 표식 
기 호가 놓인 다. 이 행 Elevator in action 이 작용되 여 발화된 다. EBf 와 F g 안의 표식 기 호들이 
제거되고 단추 EBf 는 꺼지며 새로운 하나의 표식기호가 F f 안에 나타난다. 이 이행의 발화 
는 승강기 가 층 g 로부터 층 f 에 로 움직 이게 한다. 

층 g 로부터 층 f 에로의 이러한 이행은 동시에 일어 날수 없다. 이것과 어떤 단추를 누 
를 때 마다 그 단추가 불이 켜질 물리 적 불가능성 과 같은 류사한 론점 들을 다루기 위하여 
시 간조절기 능이 페 트리 망모형 에 추가되 여 야 한다. 즉 고전적페 트망리 론과는 반대 로 승강기 
문제와 같은 실천적정황에서 이행들은 동시적이며 하나의 령 아닌 시 간을 하나의 이 행과 
관련시 키 기 위 하여 시 한페 트리 망 ( rtmec / PefrheO 들이 필 요하다 [Coolahan and Raussopoulos , 


EB f pressed EB f blavator 
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1983]. 

두번째 제약 1층과 마지 막층을 제 외 하고 매층은 두개 의 단추를 가진다. 한개 는 승강 
기 상승을 요청하며 다른 한개 는 승강기하강을 요청한다. 이 단추들을 누를 때 불이 켜 진 
다. 승강기가 대응하는 층을 찾아 가고 그다음 요구하는 방향으로 움직일 때 그 단추의 
불은 꺼진다. 

FB 문층단추들은 마디점 F 막 와 FB # 들로 표시 되 는데 이 것 들은 각각 승강기 상승 및 
하강을 요청하는 단추들을 표시 하고 있다. 보다 정 확하게 말하면 층 1은 단추 FB } 1 를 
가지 며 층 m 은 단추 FB ^ 를 가지 며 매 중간층들은 두개 의 단추 FB ^ 와 FB ᄅ 1산<01를 
가진다. 하나의 승강기가 하나 또는 두개의 단추가 불이 켜진 층 g 로부터 층 的1 도달할 
때의 정황을 그림 11-23 에 보여 주었다. 사실 이 그림은 더 정교하게 묘사하여야 한다. 
왜냐하면 만일 단추 두개가 다 불이 켜 지 면 비 결 정론적기 준에 의하여 하나는 꺼 지 기 때 문 
이다. 



그림 11-23. 층단추의 페트리망표현 
[Guha, Lang, and Bassiouni, 1987], (©1987 IEEE.) 

단추가 정확히 꺼진다는것을 확인하기 위하여서는 너무 복잡한 페트리망이 필요하기 
때 문에 여 기서는 제시 하지 않는다. 실례 로 문헌 [Ghezzi and Mandnoli , 198기을 보시 오. 

세번째 제약 승강기에 아무런 요청도 없을 때 승강기는 문을 닫은채로 현재의 층에 
머물러 있는다. 

이것은 쉽게 달성 할수 있다. 즉 만일 아무런 요청도 없으면 아무런 Elevator in action 
이행도 작용되지 않는다. 

페트리 망은 명세 서 를 표현하기 위하여 리용될뿐아니 라 설계 를 위 해서 도 리용될수 있 
다 [ Guha , Lang , and Bassiouni , 1987]. 제 품개 발의 명세 작성 단계 에서만 보아도 페트리망이 


361 



병행체계의 동기화측면을 명시하기 위하여 필요한 표현능력을 가지고 있다는것은 명백 
하다. 


11. 8. z 

현재 광범한 인기를 끌고 있는 한가지 형 식적명세작성언어는 Z 이 다 [ Spivey , 1992 ](Z 
의 이 름을 정 확히 발음하기 위 하여 서 는 다음의 《 알고 싶은 문제》를 보시 오.). 표를 리 
용하기 위하여서는 1계 론리를 비롯하여 모임론, 함수, 리산수학에 대한 지식이 필요하다. 
필요한 배경지식(대부분의 콤퓨터과학전공과목들)을 가진 사용자들조차 Z 는 처음에 배우 
기 어렵다. 왜냐하면 Z 는 3,^、다와 갈은 일반적인 모임론적 및 론리적기호들외에 田， 
■적 h +, >+ 와 같은 잘 쓰이 지 않는 특수기 호들도 리용하기 때 문이 다. 


알:2 싶 e ©제 

형 식적 명세작성언어 에 대 한 Z 라는 이 름은 그 창시 자 진 레 이 몬드 아브리 알 ( Jean-R ymond 
Abrial ) 이 뛰 여 난 모임론학자인 에른스트 프레 드리 츠 페 르디 난드 제 르멜 로 (Ernst F iedrich 
Ferdinand Zermelo )(1871-1953) 에 게 경의를 표시 하여 지 었다. 이것은 옥스포드대 학< 서 개 
발되 였기 때 문에 [ Abrial , 1980] Z 라는 여름을 영 어 자모 26번째 를 영 국식 으로 발음하- - 방식 
으로 《 zed 》 라고 적 당히 발음한다. 

그러나 최근에 표가 독일수학자의 이름을 따서 지었다는것을 인정하고 그것을 독1 식으로 
《 Izet 》 라고 발음하려는 움직임이 보이고 있다. 이에 대응하여 프란코훨레스 (Francop iles ) 와 
프란코호네 스크 ( Francophonesk ) 는 아브리 알이 프랑스사람이 라는것 과 문자 표가 프링 i 식 으 
로《 zed 》라고 발음된 다는것 을 지 적 하였 다. 

총적으로 수용할수 없는 한가지 발음은 미국식으로 그것을 《 zee 》 로 발음히 는것이 
다. 그 리 유는 Z (《 zee ) 라고 발음)가 4세 대 프로그람작성언어 의 이 름이 기 때 문이 다 (1 .2) 그 
러 나 영 어자모의 한개 문자에 상표를 붙일수 없다. 더우기 우리는 문자 Z 를 원하: • 방식 
으로 자유롭게 발음하고 있다. 그러 나 프로그람작성언어의 범위내 에서 《 zee 》 라- ■ 발음 
은 4 GL 과 관계되여 있고 형식적명세작성언어와는 관계되지 않는다. 


Z 가 제 품을 명 시하는데 리용되 는 방법 을 파악하기 위하여 11.6.1 의 승강기문제 를 다 
시 고찰하자. 


11. 8. 1 . 승강기문제: Z 

가장 간단한 형식 으로 z 는 다음의 네 부분으로 구성된다. 

1. 주어 진 모임，자료류형，상수 

2. 상태정의 

3. 초기상태 
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4. 조작들 

이 매 부분들을 차례로 고찰하자. 

1. 주어 진 모임 (Given Sets ) Z 명세서는 주어 진 모임들의 목록 즉 세부적으로 정의될 
필요가 없는 모임들로 시작한다. 이와 갈은 임의의 모임들의 이름은 중괄호안에 나타난 
다. 승강기문제 에 서 주어 진 모임 은 모든 단추들의 모임 인 Button 으로 불리 울것 이 다. 
그러므로 Z 명세서는 


[ Button ] 


으로 시 작한다. 

2. 상태정의 Z 명세서는 많은 도식 ( sc /? em 비들로 구성된다. 

매 도식들은 변수들의 가능한 값들을 제한하는 술어들의 목록과 함께 변수선언들의 
그룹으로 이루어 진다. 도식 S 의 형식을 그림 11-24 에 보여 주었다. 

- S - 

declarations 

predicates 


그림 11-24. Z 도식 S 의 형식 

승강기문제 에서 는 Button 에 대 한 4 개 의 부분모임 이 존재한다. 즉 층단추들, 승강기단 
추홍 buttons (승강기 문제 에 서 모든 단추들의 모임)와 pushed (눌러 워 진 단추들의 모임)이 
다. 그림 11-25 는 도식 Button _ state^r 묘사하고 있다. 기호 P 는 제곱모임(주어 진 모임의 
모든 부분모임 들의 모임)을 의 미한다. 

제 약들 즉 수평선 아래의 설명 문들은 floor_buttons 와 elevator_buttons 모임들이 분리 되 여 
있으며 그것들이 합쳐 져서 buttons 모임을 구성한다는것을 서술하고 있다 ( floor_buttons 와 
elevator_buttons 모임 들은 이 후에 는 필 요 없 다. 즉 그것 들은 Z 의 능력 을 보여 주기 위하여 
만 그림 11 -25 에 포함된다.). 


P Button 
P Button 

PButton 
— 

= buttons 


그림 11-25. Z 도석 Button_State 

3. 초기상태 추상적 초기 상태 ( afc / rac / initial state ) 는 체계가 처음 시동될 때의 상태를 
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서술한다. 승강기문제에 대한 추상적초기상태는 다음과 같다. 


Button_Init = [ Button _ State ' \ pushed - 0] 

이 것은 수직 형도식정의 ( verft ’ ca / schema c 쓱/? m 次 on ) 이며 그림 11-25 에 보여 준것과 같은 
수평 구도정 의 {horizontal schema definition ) 와 반대 이 다. 수직 형 도식 은 승강기 가 처 음 시 동 
하였을 때 모임 pushed 는 초기에 비여 있다는것 즉 모든 단추들이 꺼져 있다는것을 서술 
하고 있다. 

4. 조작 어떤 단추를 처음 누르면 그 단추에 불이 켜 진다. 그 단추는 모임 pushed 에 
첨부된다. 이것은 그림 11-26 에 보여 주고 있는데 거기에서 조작 Pws/iSMtow 이 정의된다. 
도식의 첫행에 있는 公는 이 조작이 Button _ State $ 상태를 변화시킨다는것을 의미하고 
있 다. 조작은 하나의 입 력 변수 button ? 을 가지 고 있 다. 기 타 여 러 가지 언 어 ( CSP [ Hoare , 
1985] 와 같은)에 서 와 마찬가지 로 의 문기 호 (?) 는 입 력변수를 의 미하며 감탄표 (!) 는 출력변 
수를 의 미한다. 

한 조작의 술어 부분은 그 조작이 호출되 기전에 준수하여 야 할 사전조건들과 그 조작 
이 실행을 끝낸후에 준수하여야 할 사후조건들의 그룹으로 이루어 진다. 사전조건들이 
만족된다는 조건하에서 사후조건들은 실행 을 완성한후에 준수될것 이 다. 그러 나 만일 그 
조작이 사전조건이 만족됨이 없이 호출된다면 명시되지 않은(그러므로 서술할수 없는) 
결 과들 이 발생할수 있 다. 



AButton_State 
button?: Button 


(button? S buttons)A 

(((button? 다 : pushed) A (pushed' = pushed U {button?})) V 
((button? £ pushed) A (pushed' = pushed))) 


그림 11-26. 조작 Push _ Button 의 Z 서술 

그림 11-26 의 첫번째 사전조건은 button ? 가 이 승강기체계의 모든 단추들의 모임인 
buttons 의 성원이 여야 한다는것을 서술하고 있다. 만일 두번째 사전조건 button ? 安 pushed 가 만 
족된다면(즉 만일 그 단추가 켜져 있지 않다면) pushed 단추들의 모임은 갱 신되 여 button ? 을 
포함한다. 고에 서 어 떤 변수의 새 로운 값은 빗점 (’) 으로 표시 된 다. 결 국 사후조건은 조작 
Push _ Button 。' 수행된 다음에 button ? 이 모임 pushed 에 추가되 여 야 한다는것을 서술하고 있 다. 
명백히 그 단추에 불을 컬 필요는 없다. button ? 이 이제는 pushed 의 요소이라는것은 충분하다. 

또 다른 가능성은 이미 눌러 진 단추를 또 누르는것 이 다. button ? epushed 이기때문에 
세번째 사전조건은 성 립*>되며 필요할 때 아무런 사건도 발생하지 않는다. 이 것은 서 술문 


세번째 사전조건이 없는 경우 명세서는 만일 이미 누른 단추를 다시 누르면 어떤 사 
건 이 일 어 나겠는가를 서 술할수 없을것 이 다. 그렇 게 되 면 결과들을 명 시할수 없을것 이 다. 
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pushed '= pushed 로 지적된다. 즉 이것은 pushed 의 새 상태는 낡은 상태와 같다는것을 의미 
한다. 

이제 승강기가 어떤 층에 도착하였다고 가정하자. 만일 대응하는 층 단추가 켜져 있다 
면 그것은 꺼져 야 하며 대응하는 승강기단추에 대 해서도 이것은 류사하다. 즉 만일 button ? 
이 pushed 의 요소이라면 그림 11-27 에 보여 준바와 같이 그림은 이 모임 으로부터 제거되 여 
야 한다(기호 \은 모임 차를 의미 한다.). 그러 나 만일 어떤 단추가 켜져 있지 않다면 모임 pus 
hed 는 변화되지 않는다. 

- Floor_Arrival - 

AButfon—State 
button?: Button 
(button? € buttons)A 

(((button? G pushed) A (pushed' = pushed \ {button?})) V 
((button? 당 pushed) A (pushed^ = pushed))) 

그림 11-27. 조작 Floor _ Arrival 의 Z 서술 

이 절에서 제시한 해 결 방법은 지 나치 게 단순화한 한가지 실례 이 다. 즉 여 기 에서 는 
승강기상승 및 하강단추를 구분하지 않고 있다. 그러 나 Z 가 승강기 문제 에서 단추들의 거 
동을 명시 하기 위하여 어 떻게 리 용될수 있는가 하는 하나의 지시를 주고 있다. 

11.8.2. 고의 분석 

Z 는 CASE 도구들 [ Hall , 1990], 실시 간핵 심부 [ Spivey , 1990], 오썰로그라프 [Delisle and Garla 
n , 199 이를 비 롯한 광범한 프로젝 트들에 성 공적 으로 리 용되 였 다. 

표는 또한 IBM 업무처 리체 계 인 CICS 배포판의 큰 부분을 명 시하는데 리용되 였다 [Nix 
and Collins , 1988]. 이 와 같은 성 공은 승강기 문제 와 같은 단순화된 경 우에 조차 Z 가 똑바 
로 리용되 지 않는다는 견지 에서 보면 좀 놀라운 일 이 다. 첫째 로，표시 법 에서 문제 가 발생 
한다. 즉 새 로운 사용자는 Z 명세서 를 읽 을수 있고 그것 을 단독으로 작성할수 있게 되 기 
에 앞서 기호모임과 그의미를 학습하여야 한다. 둘째로, 매 쏘프트웨어공학자들이 Z 를 
리용할수 있는 그런 필요한 수학적숙련이 없다는것 이 다(비록 거의 모든 콤퓨터과학과정 
안을 마친 최근 졸업생들이 z 의 리용과 관련한 충분한 수학을 알고 있거나 그들이 알아 
야 할 필요가 있는것을 쉽게 배울수 있다 하여도 그렇다.). 

표는 아마도 그와 같은 류형의 언어들가운데서 가장 광범히 리용된 형식언어이다. 이 
것은 무엇때문인가? 왜 표가 그토록 성공적인가? 특히는 대규모프로젝트에서 성공적인가? 

여러가지 각이한 리유들이 제시되였다. 

1. 프로 작성한 명세서들에서 특히 명세서자체의 검토와 설계나 코드의 검토기간에 
오유를 찾아 내 는것 이 형 식 적 명 세 서 에 비 하여 쉽 다는것 이 밝혀 졌 다 [Nix and 
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Collins , 1988; Hall , 1990]. 

2. Z 명세서 를 작성하는것 은 명세작성 자가 극히 정 확할것 을 요구한다. 즉 이 러 한 정 
확성에 대한 요구의 결과로서 Z 명세서에는 비형식적명세서들보다 애매성，모순， 
생략이 더 적게 나타난다. 

3. 형식언어로서 Z 는 개발자가 필요할 때 명세서의 정확성을 증명할수 있게 한다. 
결 국 비 록 일 부 쏘프트웨 어개 발기 업 체 들은 고의 정 확성증명 을 거 의 할수 없 다고 
하여 도 CICS 기 억 관리 자와 같은 실 천적 문제 들에 서 까지 이 와 갈은 증명 이 진행 되 였 
다 [ Woodcock , 1989]. 

4. 고등학교 수학지식 만을 가진 쏘프트웨어 전문가들이 상대 적 으로 짧은 시 간내 에 Z 
명세서를 작성하도록 가르칠수 있다는것이 제기되였다 [ Hall , 1990]. 명백히 이러한 
개별적사람들은 결과적인 명세서가 정확하다는것을 증명 할수는 없지만 형식적명 
세서 는 그 정 확성 을 반드시 증명하여 야 하는것 이 아니 다. 

5. Z 의 리용은 쏘프트웨어의 개발비용을 감소시켰다. Z 명세서자체에는 비형식적기법 
을 리용할 때보다 더 많은 시간이 소비되여야 한다는것을 의심할 여지가 없지만 
완전 한 개 발공정 에 소비 되 는 총적 시 간은 감소된 다. 

6. 의뢰자가 프로 쓴 명세서를 리해할수 없다는 문제는 그 명세서를 자연언어로 다시 

쓰는것을 비롯한 여 러가지 방법으로 해결되였다. 

결과적 인 자연언어명세서는 처 음부터 작성된 비형식 적명세서보다 더 명 백 하다는것 이 
밝혀 졌다(이것은 또한 11.2.1 에서 서술된 나우르의 본문처리문제에 관하여 메이어의 형 
식적명세서에 있는 영어단락으로부터 얻은 경험이다.). 

가장 중요한것 은 모순되 는 론의에 도 불구하고 Z 가 많은 대 규모프로젝 트들에 관하여 
쏘프트웨 어산업 에서 성공적 으로 리용되 였다는것 이 다. 대 다수의 명세서 들이 비 록 Z 보다는 
매우 덜 형식적인 언어로 계속 작성된다고 하여도 형식적언어의 리용을 지향하는 대역적 
추세는 증대되고 있다. 이와 같은 형식적명세서는 전통적으로 유럽의 실천에서 많이 리 
용되 여 왔다. 그러 나 점점 더 많은 쏘프트웨 어개 발기 업 체들이 한가지 또는 기 타 형 식적 
명세작성법을 받아 들이고 있다. Z 와 그와 류사한 언어들이 앞으로 어느 정도 리용되겠 
는가는 두고 보아야 한다. 


11.9. 기타 형식적기법 

기타 많은 형식적기법들이 제안되였다. 이 기법들은 매우 다양하다. 실례로 Anna[Luckham 
and von Henke , 1985] 는 Ada 용형 식 적 명세서작성 언어 이 다. 일부 형 식적 기 법들은 Gist [ Balzer , 
1985] 와 같은 지식에 기초한 기 법들이다. Gist 는 우리들이 공정에 대 하여 생각하는 방법 
과 될수륵 가까운 방법으로서 사용자들이 공정을 서술하도록 자기의 기 법을 설계하였다. 
이것은 자연언어 에서 리용된 구조들을 형식 화함으로써 달성할수 있었다. 사실 Gist 의 명 
세서는 기타 대다수 명세서들처럼 Gist 명세서로부터 영어로 의역하는 의역기가 작성될 
정 도로 리해 하기 어 렵 다. 
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원정 의방법(的 definition method ，， VDM )[ Jones , 1986 b ] 은 외 연적의 미 론에 기 초 
한 기법이다 [ Gordon , 1979]. VDM 은 명세 작성에 뿐 아니라 설계와 실현단계 에도 적용될 
수 있 다. 

VDM 은 많은 프로젝 트들에 서 성 공적 으로 리 용되 였 다. 특히 DDC(Dansk Datamatik 
Center ) Ada 콤파일러체계의 개발에서 가장 성공적으로 리용되였다 [ Oedt , 1986]. 

명세서를 고찰하는 다른 한가지 방법은 그것들을 사건들의 순서렬로 간주하는것이다. 
여 기서 하나의 사건은 하나의 단순한 작용이든가 자료를 체 계안으로 또는 밖으로 전달하 
는 하나의 정보전달이다. 실례로 승강기문제에서 하나의 사건은 승강기 e 에서 층 神ᅵ 대한 
승강기단추를 누르고 그 결과 그 단추에 불이 켜지는것으로 구성된다. 또 다른 사건으로는 
승강기 e 가 아래방향을 향하여 층 f 를떠나고 대응하는 층단추의 불이 꺼지는것을 례로들 
수 있 다. 호아 ( Hoare ) 가 발명 한 언어 통신순차과정 ( Cbwwwm ’ caft’ng &우 / Vocewas ; CSP ) 
은 이와 갈은 사건들로서 체계의 기동을 서술하려는 착상에 기초하고 있다 [ Hoare , 
1985]. CSP 에서 하나의 공정 은 그 공정 이 관계하게 될 환경 에서의 사건들의 렬로서 서술 
된다. 공정 들은 통보들을 서 로 보내 는것 으로서 호상작용한다. CSP 는 공정 들이 순차적으 
토, 병렬로, 비결정론적으로 분리되는것과 같이 다양한 방법으로써 결합되도록 한다. 

CSP 의 능력은 CSP 명세서의 실행가능한 성질에 있다 [Delisle and Schwartz , 198刀. 따 
라서 명세서들의 내부적일치성을 검사할수 있다. 더우기 CSP 는 매 단계들에서 타당성을 
유지 하면서 명세작성 으로부터 설계 에 로 또 실현에 로 이 행 하기 위한 틀거 리 ( frameww 次)를 
제공하여 준다. 달리 말하면 만일 명세서들이 정확하고 변환이 정확하게 수행된다면 설계 
와 실현 역시 정확하게 진행될것이다. 만일 실현언어가 Ada 이라면 설계로부터 실현에로 
이 행하는것 은 매 우 간단하다. 

그러 나 CSP 도 자기 의 약점 을 가지 고 있다. 특히 Z 와 마찬가지 로 그것 을 배 우기 가 
쉽지 않다. 승강기 문제 에 대 한 CSP 명세세 Schwartz and Delisle , 198刀를 이 책 에 포함시 키 
려 고 시 도하였 었 다. 그러 나 본질 적 인 예 비자료들의 질 과 매 CSP 서 술을 적 절 하게 서 술하 
는데 필요한 설명 의 세 부준위 가 너 무 방대하여 이 책 과 같은 밀반적 인 한 권의 책 에 그 
것을 포함시키기는 어렵다. 명세작성언어의 능력과 그 리용의 어려운 정도사이의 관계에 
대 하여 서 는 다음절 에 서 설명한다. 

11. 10. 명세작성기법들의 비교 

이 장에서의 중요한 교훈은 매 개발기업체가 어느 류형의 명세작성언어가 개발될 제 
품에 적 합한가를 결정하여 야 한다는것 이 다. 비형식적기 법을 배우기는 쉽지만 준형식적 인 
또는 형식적인 기법이 가지고 있는 능력이 결여되여 있다. 거꾸로 매개의 형식적기법들 
은 각이한 특성들을 지원하고 있는데 이러한 특성들에는 실행가능성，정확성증명，단계별 
정확성을 유지하면서 설계 및 실현에로 변환하는 가능성들이 포함된다. 일반적으로 그 
기법이 보다 형식적일수록 그 능력은 더욱 커지며 형식적기법들을 리용하고 배우기가 어 
려울수 있다. 또한 형식적명세서는 의뢰자가 리해하기 어려울수 있다. 달리 말하면 명세 
작성언어의 리용과 능력사이에는 절충을 하여야 한다. 
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일부 정황에서 명세작성언어의 류형을 선택하는것은 쉽다. 실례로 만일 대다수의 개 
발림성원들이 콤퓨터과학에 대하여 아무런 파악도 없다면 비형식적 또는 준형식적명세작 
성기법이 아닌 다른 기법을 리용하는것은 사실상 불가능하다. 거꾸로 기업에 사활적의의 
를 가지는 실시간체 계를 실험실에서 구성 하고 있다면 여기 에서는 형식적명세작성기 법 이 
거의 틀림없이 요구될것이다. 

추가적인 한가지 복잡한 인자는 대부분의 보다 새로운 형식적기법들은 실천적조건에 
서 검증되지 않았다는것이다. 이러한 기법을 리용할 때 상당한 위험성이 포함된다. 관련 
있는 개발림성원들을 양성하는데 막대한 자금을 투자해야 하며 또한 개발림이 연구실에 
서 그 언어를 리용하는것으로부터 실지프로젝트에서 리용하는것을 조종하는 기간에 보다 
많은 자금이 소비되는것이다. 더우기 그 언어들이 지원하고 있는 쏘프트웨어도구들이 
SREM 에서처 럼 적 당하게 동작하지 않을수도 있으몌 Scheffer , Stone , and Rzepka , 1985] 결 
국 추가적 인 지 출과 기 한어김 이 초래 될 수 있 다. 

그러 나 만일 모든것 이 동작하며 쏘프트웨어의 유지정 비계획 에서 새 로운 기 법을 특수 
한 프로젝 트에 처 음으로 리용할 때 필요되 는 추가적 인 시 간과 자금을 고려 한다면 많은 
리 득이 차례질수 있 다. 


서술방법 

범주 

우 점 

약 점 

자연언어 (11.2) 

비형식적 

배우기 쉽다. 

리용하기 쉽다. 

의뢰자가 리해하기 쉽다. 

부정확성 

설계명세가 애매하고 보卷 
이 있고 그리고/혹은 불완 
전하다. 

실체-관련 모형 화 
(11.5) 

PSL / PSA (11.4) 

SADT (11.4) 

SREM (11.4) 

구조화체 계 분석 

(11.3) 

준형식적 

의뢰자는 비형식적인 방 
법보다 더 정확히 리해할 
수 있다. 

형식적방법만큼 정확치 못 

하다. 

일반적으로 시간을 조종할 
수 없다. 

Anna (11.9) 

CSP (11.9) 

확장된 마감상태 
기계 (11.6) 

요점 (11.9) 

페 트리 망 (11.7) 
VDM (11.9) 

Z (11.8) 

형식적 

아주 정확하다. 

설계명세오유를 줄일수 
있 다. 

개발비용과 노력을 줄일 
수 象다.. 

정확성중명을 지원할수 
있 다. 

배우기가 힘들다. 

리용하기 힘들다. 

대부분 사용자들이 거의나 
리해할수 없다. 


그림 11-28. 이 장에 서 론의 한 명세작성 방법 의 개 요와 해 당한 절 



이 런 특정 한 프로젝 트에 어느 명세 작성 기 법 들을 리 용하여 야 하는가 ? 이것은 프로젝 
트, 개발림，경영림 그리고 의뢰자가 어떤 특정한 방법을 리용하겠다고(또는 리용하지 않 
겠다고) 고집하는것과 갈은 무수히 많은 다른 인자들에 의존하고 있다. 쏘프트웨어공학 
의 많은 측면들에서와 마찬가지로 절충을 하여야 한다. 그러나 유감스럽게도 어느 명세 
작성기법을 리용하겠는가를 결정하기 위한 그 어떤 단순한 규칙도 없다. 

그림 11-28 은 이 절의 착상에 대 한 종합이다. 


11. 11. 명세작성단계에서의 시험 

명 세 작성 단계 에 서 목적 하는 제 품의 기 능성 이 명 세 서 에 명 확히 표현된 다. 명 세 서 가 
정 확한가를 검 증하는것 은 사활적 인 문제 이 다. 이것 을 위한 한가지 방도는 명세서관통심 
사회 의 에 의 거 하는것 이 다 (6.2.1). 

명세서 에서 오유를 발견하기 위한 보다 강력한 수단은 검토이 다 (6.2.3). 검 토림 은 검사 
목록과 대 비하여 명세 서 를 심 사한다. 명세검 사목록의 전형 적 인 항목들에는 다음과 같은 
것들이 포함된다. 

필요한 하드웨 어자원들이 명시되 였는가? 

수용판정기 준이 명시되 였는가? 

설계와 코드의 검토와 관련하여 파간 ( Fagan ) 이 처음으로 검토 O 행 ecton ) 방법을 제안 
하였다 [ Fagan , 1976]. 파간의 론문은 6.2.3 에 자세히 서술되여 있다. 그러나 검토는 명세서 
를 검 토하는데 도 상당히 쓸모 있 다는것 이 증명되 였 다. 실례 로 둘렌 ( Dodan ) 은 2백 만행 이 
상의 FORTRAN 언어로 구성된 제품명세서를 검증하는데 검토를 리용하였다 [ Doolan ，1992]. 
제 품에 있는 오유를 수정 하기 위한 비 용에 대 한 자료로부터 그는 검 토에 투자된 매 한시 
간이 실행에 기초한 오유검사와 정정에 드는 30 h 을 절약한다는것을 추론해 내였다. 

명세서가 형식적기법을 리용하여 작성되였을 때 다른 시험기법들이 리용될수 있다. 
실례 로 정 확성증명방법 들 (6.5) 이 도입 될수 있다. 만일 형 식 적 증명 이 진행 되 지 않는다고 
하여도 6.5.1 에서 리용된것과 같은 비형식적증명기법들은 명세서의 오유를 밝혀 내기 위 
한 매우 유용한 방법으로 될수 있다. 사실 제품개발은 그것의 증명과 병렬로 진행되여야 
한다. 이런 방법으로 오유들은 신속히 발견된다. 

11. 12. 명세작성단계에서의 CASE 도구 

명세작성단계에서 두가지 부류의 CASE 도구들이 특히 도움이 된다. 첫째는 도형도구 
이다. 어떤 제품이 자료흐름도, 페트리망, 실체-관련도를 리용하여 표현되든지 아니면 지 
면상리유로 하여 이 책 에서 언급하지 않은 기 타 여 러 가지 방법 으로 표현되 든지간에 전체 
적 인 제 품을 수동적 으로 작성하는것 은 시 간이 많이 드는 공정 이 다. 더우기 부분적 인 변 
경 을 진행하는것 이 모든것 을 처 음부터 재작성해 야 할 결 과를 초래할수도 있 다. 그렇 기때 
문에 그리 기 도구는 시 간을 크게 절 약하게 한다. 명세서 를 위한 기 타 여 러 가지 도형표현 
들이 있는것처럼 이러한 류형의 도구는 이 장에서 서술되는 명세작성기법에도 있다. 명 
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세작성단계 에 서 요구되 는 두번째 도구는 자료사전이 다. 5.4 에 서 언급한것 처 럼 이 도구는 
자료흐름과 그 요소들，자료저 장과 그 요소들, 처 리(작용)와 그 내부변수들을 비롯하여 
제품의 매 자료항목의 매 요소들의 이른바 표현(형식)들을 저장하고 있다(그림 11-5 는 쌜 
리의 쏘프트웨 어상점 을 위한 자료사전에 기 억될 전형적 인 정 보들을 보여 주고 있다.). 또 
한 자료사전의 많은 부분이 각이한 하드웨 어 상에 서 운영 된 다. 

실지로 필요한것은 개별적인 도형도구와 개별적인 자료사전이 아니다. 그대신 이 두 
도구는 통합되여야 한다. 그리하여 자료요소에 대하여 진행한 임의의 변경은 명세서의 
대응하는 부분에서 자동적으로 반영되도록 하여야 한다. 이러한 류형의 도구들에 대한 
실례들로 는 분석기/설 계기 {Analyst/Designer), 그림을 통한 쏘프트웨어 (Software through 
Picture), 체계 구성 (切없 em 쇼 ctoecft / re ) 들을 들수 있 다. 더 우기 이러한 여러가지 도구들에 
는 명세 서 와 대 응하는 설계문서사이 의 일 관성 을 검 사하는 자동일 관성 검 사기 가 병 합되 여 
있다. 실례로 명세서안의 매 항목이 설계문서에 선행하여 수행되며 설계에 언급된 모든 
것 이 자료사전에 선언되 였다는것을 검 사할수 있다. 명세작성기법은 그 기법을 지지하는 
풍부한 도구를 가진 CASE 환경 이 없으면 광범하게 리용될수 없을것 이 다. 실례 로 
SREM (11.4) 은 아마도 현재 REVS 보다도 훨씬 광범 히 리 용되 는것 같은데 그와 관련된 
CASE 도구모임은 미공군에서의 시험을 보다 훌륭히 수행하였다 [ Scheffer , Stone , Rzepka , 
1985]. 경험 있는 쏘프트웨어전문가들에 있어서도 어떤 체 계를 정 확하게 명시하는것은 
쉬운 일 이 아니 다. 명세작성 자들에게 가능한 모든 방법 으로 그들을 도와 주는 최첨 단 
CASE 도구들의 모임 을 제 공하는것 만이 합리 적 일 것 이 다. 

11. 13. 명세작성단계에서의 척도 

명 세작성 기 간에 다른 모든 단계 들과 마찬가지 로 5개 의 기 본척 도 즉 크기 , 비 용, 기 간， 
토력，품질을 측정하는것 이 필요하다. 어 떤 명세서의 크기 에 관한 한가지 척도는 명세서 
의 폐지수이다. 만일 여러가지 류사한 제품들을 명시하기 위하여 같은 기법을 리용한다 
면 명세서크기 에서 의 차이 는 여 러 가지 제 품을 만드는데 필요한 토력 에 대 한 중요한 예 측 
인 자로 될수 있 다. 

품질 문제 를 고찰하면 명세 서검 토의 한가지 중요한 측면은 오유통계 에 대 한 기 록이 다. 
검토기간에 발견한 매 류형의 오유개수를 적어 놓는것은 검토공정에서 필수적 인 부분이 
다. 또한 오유검출률도 검토공정의 효과성에 대한 척도를 줄수 있다. 

목표제품의 크기를 예 측하기 위한 척도는 자료사전에 들어 있는 항목개수들을 포함 
한다. 파일, 자료항목, 처 리(작용)의 개 수를 비 롯하여 여 러 가지 각이한 계 수가 진행 될수 
있다. 이러한 정보는 그 제품을 만드는데 요구되는 토력을 고려하여 관리자측에게 초보 
적인 평가를 줄수 있다. 이 정보는 기껏해서 림시적이라는것을 주의해 두어야 한다. 결국 
설계 단계 에서 DFD (자료흐름도)안의 하나의 처 리를 서로 다른 여 러개의 모둘안에 갈라 
넣 을수 있다. 반대 로 여 러개의 처 리 들을 묶어 하나의 모둘을 구성할수도 있다. 그러 나 자 
료사전으로부터 유도된 척도는 관리자측에게 목표제품의 최종크기에 관한 하나의 조기 
실머리를 줄수 있다. 
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11. 14. 항공음식전문회사실례 연구 : 

구조화체계분석 

요구사항확정 단계에서 신속원형 작성에 뒤이 어 신중한 면담을 진행하기때문에 게인과 
사르센의 구조화체 계 분석 공정 은 실제 적 으로 수행 하기 간단하다. 최 종자료흐름도를 그림 
1卜29에 보여 주었다. 

자료흐름도 ( DFD ) 의 중추적요소는 자료의 저장인 특별식사자료 (SPECIAL MEAL 
DATA ) 이다(그림 11-29 의 중심에서 열린 직사각형으로 표시). 저장용자료는 3개의 원천으 
로부터 얻어 진다. 즉 비행기 안내원 (FLIGHT ATTENDANT ) 에 의하여 조사되는 식사보고 
서 (웃단 왼쪽)，예약자료 (RESEVATION DATA ) 의 저장(웃단 중간), 승객 ( PASSENGER ) 의 
식사값을 포함하고 있는 조사된 우편엽서(웃단 오른쪽)이다. 자료의 저장 특별식사자료로 
부터 엄어 지는 특정한 special meal cbtails 는 그림 11-29 의 중간부아래에서 6개의 둥근 
직 사각형 으로 표시 된 공정 에 의하여 6개 의 보고서 를 발생 시키 는데 리 용된 다. 

하나의 보고서 를 발생 하기 위 하여서는 그 보고서 의 시 작과 마감날자 Otort am / em / 
cfote ) 가 그 보고서의 령수자로부터 제공되 여 야 한다(령수자들은 그림 11-29 의 아래 에 있 
는 4개 의 2중통들의 행 으로 표시된다.). 

자료흐름도는 자료의 흐름을 고찰하는것으로서 구성되였다. 먼저 매 보고서들을 차 
례로 고찰하자. 하나의 보고서에 대한 입력은 두개의 부분 즉 special meal details 과 start 
and end date 로 구성 된 다. special meal details 는 SPECIAL MEAL DATA 의 저 장으로부터 
생 겨 나며 start and end data 는 매 보고서의 령수자로부터 제 공된다. 그러므로 그림 11-29 
의 아래단 절 반은 매 보고서 와 매 보고서 의 목적 지 에 대 한 입 력 자료를 분석 함으로써 구 
성 되였다. 

SPECIAL MEAL DATA 의 원천들이 분석되였다. 즉 자료호출에서 이 부분은 그림 11- 
29의 웃단절반을 구성하는데 리용되였다. 특별식사자료를 얻을때 첫단계는 상관된 예약 
-^1 - y - {reservation details ) 를 얻 는것 이 다. 이 정 보는 예 약입 력 msemzft ’ cw ) 을 처 리 하기 

위 하여 PASSENGER 에 의 하여 제 공되 며 (그림 11-29 의 웃단 오른쪽 구석 ) RESERVATION 
DATA (그림 11-29 의 웃단 절반의 중간에 있는 자료저 장)에 저장된다. 

그다음 처 리 특별식 사요구추출 ( ex / rac / sjoeda / wea / r 예 weste ) 이 DFD 에 추가되 여 련관된 
세부들을 SPECIAL MEAL DATA 에 전송한다. 다음으로 탑승자료 ( o «~ wc / data ) 를 고찰하자. 

매 개의 탑승자료가 FLIGHT ATTENDANT 를 위 하여 생성되 여 야 하며 그다음 FLIGHT 
ATTENDANT 는 그 보고서를 완성하고 조사한다. 이 자료흐름은 그림 11-29 의 웃단 오른 
쪽 구석 에 서 통으로써 모형화되 고 화살표로 표식되 였 다. 앞에 서 와 마찬가지 로 자료흐름 
도의 이 부분은 련관된 자료흐름，그것의 원천과 목적지 그리고 그것을 보내는 공정들을 
고찰함으로써 구성되 였 다. 우편엽 서 의 보내 기，반환，조사도 류사하게 취 급되 였 다. 매 우 
편엽서는 SPECIAL MEAL DATA 에 있는 자료를 리용하여 생성 되 며 우편엽서 를 쓰고 그 
것을 돌려 주는 련관된 PASSENGER 에게 보내진다. 자료흐름의 이 고리는 그림 11-29 의 
웃단 오른쪽 구석 에 서 통으로 모형화되 고 화살표로 표식되 였 다. 또한 일 단 이 자료흐름 
의 원천과 목적지가 식별되고 련관된 공정이 결정되면 이 자료흐름을 DFD 에 추가하는것 
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구조화체 계분석 의 나머 지 부분은 부록 5에 서 제 시 된다. 부록 5에 서 의 자료의 조직 과 
제시는 의뢰자가 무엇을 작성하려고 하는가를 신속정확히 리해할수 있도록 되여 있다. 
그러나 이러한 리해를 가지는데서 중요한 인자는 의뢰자가 요구사항확정단계에서 신속원 
형 을 실 험할수 있 어 야 한다는것 이 다. 

11. 15. 항공음식전문회사 실례연구 : 

쏘프트웨어프로젝트관리계획 

이제 명세서가 완성되고 비용 및 기한평가를 비롯한 쏘프트웨어프로젝트관리계획이 
작성된다고 하자(제9장). 쏘프트웨어개발기업체가 항공음식전문쏘프트웨어제품을 개발하 
기 위하여 작성한 쏘프트웨어프로젝트관리계획 ( SPMP ) 을 포함하고 있다. 이 계획은 IEEE 
SPMP 형식을 만족시킨다 (9.5). 

11. 16. 명세작성단계에서의 난관 

이 장에서 반복되는 화제는 명세서는 의뢰자가 리해하기 충분하게 비형식적이여야 
하며 동시에 개발림이 구성될 제품에 대한 유일한 설명으로서 리용하기 충분하게 형식적 
이여야 한다는것이다. 명세작성단계에서의 하나의 중요한 난관은 바로 이 모순을 해소하 
는것이다. 그에 대한 답변은 쉽지 않다. 반대로 이 두 대치되는 목적들사이에는 영구적모 
순이 놓여 있으며 개발림令 이러한 진퇴량난을 안전하게 조절하기 위하여 최선을 다해야 
한다. 

명세작성단계에서의 두번째 난관은 명세서 (’’ 무엇”)와 설계 (’’ 어떻게")사이의 계선을 혼 
돈하기 쉽다는것이다. 명세서는 그 제품이 무엇을 하여야 하는가를 서술하여야 한다. 즉 
명세서는 그 제품이 어떻게 그것을 하게 되는가를 서술하지 말아야 한다. 실례로 어떤 
의뢰 자가 일정한 망경 로분할계산이 수행될 때 마다 0.05 s 를 넘지 않는 응답시 간을 요구한 
다고 가정하자. 명세서는 이것을 정확하게 서술하여야 하며 그이상은 필요 없다. 특히 
명세서는 이러한 응답시간을 달성하기 위하여서는 어느 알고리듬이 리용되여야 하는가 
를 서 술하지 말아야 한다. 즉 하나의 명세서 는 모든 제 약들을 렬거하여 야 하지 만 이 러 
한 제약들이 어떻게 달성되는가를 절대로 서술하지 말아야 한다. 

이와 같은 잠재적인 함정에 관한 또 하나의 실례는 자료흐름도에서 찾아 볼수 있다 
(11.3.1). 여기서 둥그런 모서리를 가진 통은 하나의 처리(작용)를 의미하고 있다. 즉 그 
것은 하나의 모둘을 의미하지 않는다. 11. 13에서 설명한바와 같이 자료흐름도 ( DFD ) 에서 
하나의 처 리는 여 러개의 각이한 모둘안에 갈라 져 들어 갈수 있으며 또 반대 로 여 러 개 
의 처 리 들이 하나의 모둘안에 결 합될 수도 있다. 중요한 점 은 처 리 로부터 모둘에 로의 이 
와 같은 개선이 명세작성단계가 아니라 설계단계에서 진행되여야 한다는것이다. 명세서 
는 목적하는 공정의 작용들을 서술하여 야 한다. 명세서는 이 작용들이 어 떻게 실현되게 
되는가를 절대로 명시하지 말아야 하며 매 처리가 할당되는 모둘조차 명시하지 말아야 
한다. 설계림의 과업은 명세서를 총체적으로 연구하고 그 제품의 최량실현을 주게 될 
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설 계 를 결정 하는것 이 다. 이 에 대 하여 서 는 제 13장에 서 서 술한다. 

제 품이 전체 로써 모둘로 분할되 였을 때 까지 는 특정한 모둘에 대 하여 작용을 할당하 
려는것은 시기상조이다. 그렇게 되면 결과는 거의 틀림없이 준최량적으로 될것이다. 

O 야 

-L 上 —I 

명세서 (11.1) 는 비형식적으로 (11.2), 준형식적으로 (11.3 부터 11.5 까지) 또는 형식적으로 
(11.6 부터 11.9 까지) 표현될수 있다. 

이 장의 주요화제는 비형식적기법이 리용하기는 쉽지만 정확하지 않다는것이다. 이 
것을 한가지 실례 로서 보여 준다 (11.2.1). 거꾸로 형 식적기 법들은 강력하지만 숙련하는데 
서 많은 시 간을 투하할것 을 필요로 한다 (1U0). 한가지 준형 식적기 법 즉 게 인과 사르센 
의 구조화체계분석이 약간 자세히 서술된다 (11.3). 여기서 설명하는 형식적기법들은 유한 
상태기계 (11.6), 페트리망 (11.7) 과 Z(11.8) 이다. 명세서검토에 관한 자료들은 11.12 에 서술 
된다. 그 다음에 명세작성단계 에서의 CASE 도구들 (11.12), 척도들을 설명 한다. 그 다음에 
항공음식전문회사 실례연구가 취급된다. 즉 그에 대한 구조화체계분석 (11.14) 과 쏘프트웨 
어프로젝 트관리 계 획 (11.15) 이 제 시 된다. 이 장은 명세작성단계의 난관에 관한 론의 로 결 
속된다 (11.16). 


보 충 

구조화체 계분석 과 관련한 중요도서들은 문헌 [DeMarco, 1978], [Gane and Sarsen, 
1979], [Yordon and Constantine, 1979] 이 다. 이 책들의 기본착상은 문헌 [Modell, 1996] 에서 
갱 신되 였다. 12.5 에 제 시된 자료지향설계 는 다른 부류의 준형 식 적명세작성 기법 들과 통합 
된 설계기 법 이 다. 그에 대 한 설명은 문헌 [Jackson, 1975; Wamier, 1976; and Orr, 1981] 에 
서 찾아 볼수 있다. SADT 는 문헌 [Ross, 1985] 에 서 , PSL/PSA 는 문헌 [Teichroew and 
Hershey, 197刀에서 론의된다. SREM 에 대 한 두개의 정 보자원은 문헌 [Alford, 1985, and 
Scheffer, Stone, and Rzepka, 1985] 이 다. 

여 섯 가지 형 식적기 법 들을 문헌 [Wing, 1990] 에서 서술하였 다. 형 식적기 법들에 대 한 
우수한 론문들은 IEEE Transactions on Software Engineering 1990 년 11 월호, IEEE 
Computer, IEEE Software, ACM SIGSOFT Software Engineering 에서 찾아 볼수 있다. 
여기서 문헌 [Hall, 199이은 특별히 흥미가 있다. 문헌 [Bowen and Hinchey, 1995b] 은 홀 
(Hall) 의 토론기사에 대한 련속이며 문헌 [Bowen and Hinchey, 1995a] 은 형식적기법들의 
리용에 관한 지도서 로 된다. 형 식적기 법들에 대 한 보충적 인 기 사들은 IEEE Transactions 
on Software Engineering 1995 년 2 월호에서 찾아 볼수 있다. 형 식적 명세 작성기 법 을 산업 에 
적용한 경우에 얻은 경험들이 문헌 [Larsen, Fitzgerald and Brooks, 1996, and Pfleeger and 
Hatton, 199 刀에서 론의 되 였 다. 형 식적 방법 들에 대 한 각이 한 견해 들은 문헌 [Saiedian et al„ 
1996] 에서 찾아 볼수 있다. 형 식적명세작성을 위한 완성모형은 문헌 [Fraser and Yaishnavi, 
199기에서 론의된다. 
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유한상태 기계방법 에 대 한 초기의 참고문헌은 문헌 [ Naur , 1964] 인데 이 것은 유감스럽 
게 도 류링기 계방법 으로 간주되 고 있 다. 상태 도표들은 FSM 에 대 한 하나의 강력한 확장으 
로 되는데 이 에 대 하여서 는 문헌 [Harel et al „ 199이에서 서 술된다. 상태 도표들에 대 한 
객체지 향확장은 문헌 [ Coleman , Hayes , and Bear , 1992, and Harel and Gery , 199 기에서 소 
개되였다. 

문헌 [ Peterson , 1981] 은 페 트리 망과 그 응용에 대 한 훌륭한 소개 도서 로 된 다. 원형 
작성 에 서 페 트리 망의 응용은 문헌 [Bruno and Machetto , 1986] 에 서 서 술되 였 다. 시 간페 트 
리망은 문헌 [Coolahan and Roussopoulos , 1983] 에서 서술되였다. Z 와 관련하여 문헌 
[ Diller , 1994] 은 흘륭한 소개 도서 로 된 다. 명세 작성 언어 에 대 한 완전한 세 부를 주는 참고 
지도서 에 관하여서는 문헌 [ Spivey , 1992] 을 보시오. Z 명세서를 리 해 할 때의 실험결과들 
을 리용하여 문헌 [ Finney , 1996] 에서는 Z 명세서들이 일부 Z 제안자들이 주장하는것처럼 
리해 하기 쉬 운가에 대 한 의 문을 제 기 하고 있 다. 

실 시 간체 계 의 명 세 작성 은 IEEE Transactions on Software Engineering 1992 년 11 월 호 
에 서 론의 된 다. 분산체 계 의 명 세 작성 은 문헌 [ Kramer , 1994] 에 서 론의 되 였 다. 쏘프트웨 어 
명세작성과 설계 에 관한 국제 토론회 회 보는 명세작성 과 관련한 연구착상들에 대 한 우수 
한 자원으로 된다. 


문 제° 

11.1. 다음의 제약들은 왜 명세서에 나타나지 말아야 하는가? 

1) 이 쏘프트웨어제품은 우리의 식료품을 서부카나다에 배달하는데서 생기는 
수송비 용을 본질 적 으로 감소시켜 야 한다. 

L ) MRI 기 억 장치 는 합리 적 인 가격 으로 설 정 되 여 야 한다. 

11.2. 다음과 갈은 구운 물고기료리법 을 고찰하자. 

원료: 

큰 옥파 1개 

랭동 오렌지쥬스 1통 

신선하게 짜낸 1개의 레몬쥬스 

빵가루 !고뿌 

밀가루 

우유 

중간크기의 서양파 3개 


** 문제 11.16( 과정 안상 목표)와 문제 11.20 과 문제 11.21( 실례 연구)는 11장과 11장의 마지 
막에 서 진행할수 있 다. 
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중간크기의 가지 2개 

신선한 물고기 1마리 

포일 리 흐이쎄 (Pouilly Fuiss 句 반고뿌 

마늘 1개 

파르마치즈 

닭알 4개 


저녁전에 레몬 1개를 즙을 내고 거르어서 그것을 랭동한다. 큰 옥파 1개와 3개의 서 
양파를 네 모나게 자르고 그것 들을 후라이관에 서 굽는다. 검 은 연기 가 없어 지 기 시 
작할 때 신선한 오렌지쥬스 2고뿌를 넣는다. 그다음 그것 을 잘 뒤 섞 는다. 레 몬을 종 
이장두께로 썰고 혼합기에 넣는다. 그동안에 버섯에 밀가루를 입히고 그것들을 우유 
에 담근 다음 빵가루가 있는 종이 봉지안에서 그것 들을 굴린 다. 국남비 에 반고뿌의 
포일리 흐이쎄를 넣고 가열한다. 170°C 에 이르면 사탕가루를 넣고 계속 가열한다. 
사탕가루가 카라멜처럼 되였을 때 버섯을 넣는다. lOmin 동안 또는 모든 덩어리들이 
없어 질 때까지 혼합기로 섞는다. 닭알을 넣는다. 이제 물고기를 집어서 거기에 프 
롭스(斤 ofc ) 를 부어서 물고기를 죽인다. 물고기껍질을 벗기고 그것을 큰 덩어리로 토 
막내 고 혼합기 에 넣는다. 끓이 기 시 작해 서 부글부글 끓어 오르면 뚜껑 을 연다. 닭알 
들은 사전에 5min 동안 휘젓개로 잘 휘저어야 한다. 물고기가 만문해 지면 그것을 큰 
접시에 담고 파르마치즈를 붓고 4min 미만 굽는다. 

이 명세서 에서 애매성，생 략, 모순들을 결정하시 오. 

11.3. 의 뢰 자의 요구를 더 정 확히 반영하도록 11.2 의 명세서단락을 수정하시 오. 

11.4. 수학공식 을 리용하여 11.2 의 명세서단락을 표현하시 오. 그것을 문제 11.3 에 대 한 
답변과 비교하시오. 

11.5. 은행 계산서 가 정 확한가를 결정 하기 위 한 제 품에 대 한 정확한 영 어 명세 서 를 작 
성 하시 오(문제 8.8). 

11.6. 문제 11.5 에 대 하여 작성한 명세서 에 대 한 자료흐름도를 그리 시 오. 작성한 DFD 
가 자료의 흐름을 간단히 반영 하고 있 으며 콤퓨터화가 진행되 였 다는 아무런 가정 도 하지 
않고 있다는것을 확인하시오. 

11.7. 문제 8.7 의 자동서고순환체 계 를 고찰하시 오. 서 고순환체 계 에 대 한 정 확한 명 세 
서를 작성하시오. 

11.8. 문제 8.7 의 서고순환체계의 조작을 보여 주는 자료흐름도를 그리시오. 

11.9. 게인과 사르센의 기법을 리용하여 문제 8.7 의 서고순환체계에 대한 명세서를 
완성하시오. 거기서 자료는 명시되지 않으며(실제로 매일 장부에 등록되고 삭제되는 책 
의 총 수) 자기 자신이 가정 하지 만 그것 들이 명 백하게 지 적된다는것을 확인하시 오. 

11.10. 하나의 류동소수점 2진수는 하나의 선택부호, 한개이상의 비트, 문자 E, 또 하 
나의 선택부호, 하나이상의 비트로 이루어 진다. 류동소수점 2진수의 실례로 11010E-1010, 
-100101E11101, +1E0 을 들수 있다. 보다 형식적으로 이것을 다음과 같이 표현할수 있다. 
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< bitstring > :: = < bit >[< bitstring >] 
< bit > :: = 0| 1 


(여 기서 […]은 선택 항목을 의 미하며 alb 는 a 또는 b 를 의 미한다.). 

입력을 문자렬로 취하며 문자렬이 타당한 류동소수점 2진수로 구성되여 있는가를 

결정하는 유한상태 기 계를 명시하시 오. 

11 . 11 . 유한상태기계방법을 리용하여 문제 8.7 의 서고순환체계를 명시하시오. 

11 . 12 . 문제 11.11 에 대 한 당신의 답이 서 고순환체 계 를 위한 차림 표구동제 품을 설계 하고 
실현하는데 어떻게 리용될수 있는가를 보여 주시오(문제 8.7). 

11 . 13 . 페트리망을 리용하여 한권의 책 이 문제 8.7 의 서 고를 순환하는것 을 명 시하시 
오. 명세서 에 조작 H , C 및 R 를 포함시키 시 오. 

11 . 14 . 당신이 도서관체계를 전문으로 콤퓨터화할 어떤 큰 회사에 근무하는 쏘프트웨 
어 기사라고 하자. 관리 자는 당신에 게 문제 8.7 의 완전한 서 고순환체 계 를 Z 로 명 시할것 을 
요구하고 있다. 당신의 답변은 무엇인가? 

11 . 15 . (과정안상 목표) 교원이 규정한 기 법을 리용하여 부록 1 에 서술된 브로드렌즈 
지역 아동병원제품에 대한 명세서를 작성하시오. 

11 . 16 . (과정 안상 목표) 부록 1 에 서 술된 브로즈렌즈지 역 아동병 원제 품을 위한 쏘프트 
웨 어 프로젝 트관리 계 획 을 작성 하시 오. 

11 . 17 . (실 례연구) 유한상태 기계방법 을 리용하여 항공음식전문회 사제 품에 대 한 요구 
사항을 작성하시오. 

11 . 18 . (실례 연구) 페 트리망을 리 용하여 항공음식전문회사제품에서 한개의 특별식사 
가 통과하는 상태 들을 명 시하시 오. 

11 . 19 . (실례연구) 11.8 의 Z 구성 을 리용하여 항공음식전문회 사제 품의 한개 부분을 명 
시 하시 오. 

11 . 20 . (실례연구) 11. 15의 쏘프트웨 어프로젝트관리 계 획은 세명의 쏘프트웨어 기사로 
구성된 소규모의 쏘프트웨어기업체를 위한것이다. 1,000명이상의 쏘프트웨어기사를 가진 
중규모의 쏘프트웨어기업체에 적합하도록 이 계획을 변경하시오. 

11 . 21 . (실례연구) 만일 항공음식 전문회 사제 품이 8주동안에 완성 되 여 야 한다면 11. 15의 
쏘프트웨 어프로젝 트관리계 획 은 무슨 방식 으로 변경되 여 야 하는가? 

11 . 22 . (쏘프 트웨 어 공학독본) 교원 이 [Bowen and Hinchey , 1995 b ] 의 복제 본을 배 
포할것 이 다. 당신은 보웬과 힌체이의 지위 에 동의 하는가 또는 당신은 《 일곱가지 희 
랍신화》의 일부가 적어도 부분적으로 사실이라고 생각하는가? 당신의 대답을 정당 
화하시오. 
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제 1 2장. 객체지향분석단계 

명세 작성 단계 를 때 로는 분석 단계治 께따 e ) 라고도 부론다. 이것은 고전적명세 작 
성 단계 에 대 응하는 객체지 향방법 을 객체지 향분석 단계 ( oty ’ ec /- on ' entec / analysis 께 owe ) 라고 
부르기때 문이 다. 이 장은 제11장에 대 응하는 객체지향방법 으로 간주할수 있다. 

12 . 1 . 객체지향분석 

객체지 향분석 ((9 슨/ analysis ; OOA) 은 객체지 향파라다임 에 대 한 준형 식 적명 
세작성기법 이 다. 제11장에서 는 여 러 가지 서 로 다른 기 법들이 구조화체계분석 에 리용되며 
그것 들은 모두 본질 적 으로 등가이라는것 을 지 적하였 다. 이 와 류사하게 현재 60 개 이 상의 
각이한 기 법 들이 OOA 에 리용되 고 있는데 새 로운 기 법 들은 하나의 규칙 에 토대하여 제 
시 된 다. 또한 이 모든 기 법 들은 대 부분 등가이 다. 이 장의 《 보충》부분에 는 각이한 기 법 
들은 물론 그 기 법 들사이의 비 교를 소개한 참고서 들이 있다. 객체지향분석 은 하나의 준 
형식적기법이기때문에 OOA 에서의 매개 기법의 본질적인 부분은 그 기법과 관련된 도형 
표시법이다. 그러므로 어떤 특정한 기법의 리용방법을 배우는것은 그 기법에서의 련관된 
도형표시 법 을 배 운다는것 을 의 미한다. 

이것은 통합모형화언어 (t/n 與 ecf Moc/e/ 初 g iangwage; UML) 의 발표와 함께 변화되였으 
며 [Rumbangh, Jacobson, and Booch, 1999] 하나의 공통적 인 표식 법 이 매 OOA 기 법 으로 리 
용되도록 설계되 였다. 이 책 에서 UML 은 객체지향분석과 객체지향설계 를 모두 표현하기 
위하여 리 용된 다. 

UML 에 대 한 보충적 인 정 보는 다음의 《 알고 싶은 문제》를 보시 오. 

객 체 지 향분석 은 세 단계 로 이 루어 진다(그것 을 아래 의 란에 종합하였 다. ) . 

1. 유스-케스모형화 ( Use-case modelling ) 이것은 각이한 결과들이 제품에 의해 어떻게 
계 산되 는가를 결 정 한다(순서 는 고려 하지 않는다.). 이 정 보를 하나의 유스-케 스도(새 e-case 
出 agram ) 와 그와 련 관된 대 본들의 형 식 으로 제 시한다 (10.12 에 서 서 술한 대 본은 유스-케 스 
의 한가지 실례 이 다.). 이 단계 를 때 로는 기능적 모형 화 modeling ) 트 부르는데 
이것은 대체로 작용지향적이다. 

2. 클라스모형화 (Class modeling ) 클라스들과 그것 들의 속성 을 결정 한다. 

그다음 클라스들사이 의 호상관계 와 호상작용을 결정한다. 이 정 보를 클라스도 ( c/au 
出 agram) 라고 부르는 실 체 -관련도와 약간 류사한 도식 의 형 식 으로 제 시한다(일 부 
저 자들은 이 도식을 콜라스모형 ( c / a ^ moc / e /) 이 라고 부론다.). 

3. 동적모형화 (Dynamic modeling ) 매 클라스 또는 부분클라스들에 의 하여 또는 그에 
대 하여 수행 되 는 작용을 결 정 한다. 이 정 보를 상태 도 (s/a/e diagnm) 라고 부르는 유한상태 
기 계 (11 .句와 약간 류사한 형 식 으로 제 시한다. 이 단계 는 작용지 향적 이 다. 
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는 짐 름바우 (Jim Rumbaugh) 에 의해 개 발되 였 으며 그 
(Schenetady) 에 있는 제네 랄 엘렉 트리니 크연구개발센터 ^ 
r Booch) 는 캘리포니아의 싼타 클라라 (Santa Clara) 에 
， Inc.) 에서 자기의 방법론을 개 발하였다. 

설명한바와 같이 모든 객체지향분석 기 법 들은 본질적오- 
도 역시 대체로 서로 등가이며 따라서 OMT 와 브츠의 
4 이 두 진영의 지지자들사이에는 언제나 승벽내기가 존 
卜황은 1994 년 W 월 름바우가 래숀널주식회사에서 브츠와 
+명의 방법론자들은 즉시 자기들의 방법을 결합한데 기초 
Me 태 o « to / ogF ) 이 라고 명명한 방법 을 개 발하기 시 작하였다 
을 때 그들이 하나의 방법 론이 아니 라 순전히 객체지향; 
한가지 표시법을 개발하였다는것이 지적되였다. 통합방 
화언어 Modeling Language ) 1 바뀌 였 다. 
i 에 객체지향쏘 a 트웨어공학의 선구자인 이와 재를손 ( l var 
그들과 합류하였다. 재곱숀은 1967 년부터 시작하여 스유 
학이 라는 자기 의 방법 론 [Jacobson, Christerson, Jonson, an 
. UML1.0 판은 1997 년에 발표되였다. 그것은 름바우, 재- 
있으며 때 로 그들은 종합적 으로 세 동 SXthree aw/gas) 로 
두제 적 인 표준이 며 그것 은 객 체 관리 그룹 ( O 切 ec « Mwage/we 
1•장되고 있으며 전 세계적인 회사재단이 객체지향파라다임나 


객체지향분석을 진행하는 방법 

다음의 세 단계 를 반복한다 : 

• 유스-케 스모형 화(대 fe-cose modeling ). 

각이한 결과들이 제품에 의하여 어떻게 계산되는가를 결정한다. 

• 들 라스모형 화 ( C 7 aw ? modeling ) 

콜라스, 믈라스의 속성, 믈라스들사이의 호상관계 를 결정한다. 

• 동적 모형 화 modeling ) 

매 클라스 또는 부분믈라스에 의하여 또는 그에 대 하여 수행 되 는 작용들을 ^ 정한다. 






실천적으로 이 세 단계들은 순수 순차적으로 수행되지는 않는다. 한 도식에서의 변화 
는 다음 두 도식에서의 대응하는 수정을 유발시킨다. 결국 00 A 의 세단계는 병렬로 효과 
적 으로 수행된다. 이것 은 객체 지향파라다임 에서 자료 (2 단계)도, 작용 (1 단계 와 3단계)들도 
다른것보다 앞설수 없기때문에 타당하다. 

00 A 는 확실 히 앞장에 서 고찰한 두개 의 구조화된 명 세작성 기법 즉 실 체 -관련 모형화 
( ERM ) 와 유한상태 기계 ( FSM ) 의 결 합으로서 간주하지 말아야 한다. 반대 로 00 A 는 3개 의 
모형 화단계 들의 결 과를 명 시 하기 위하여 도식 들을 리용하는 하나의 모형화기법 이 다. 이 
정 보를 현시하는 새 로운 방법 들을 총체 적 으로 창안하는것 대 신에 광범히 리용되 고 있는 
구조화된 기법들에 기초한 표시법을 받아 들이는것 이 타당하다. 

이 것을 고찰하기 위 한 또 한가지 방법은 00 A 의 목적 이 기 타 모든 명세작성기법들 
과 마찬가지 로 구성 될 목표제 품을 명 시하는것 이 라는것 을 옳바로 인식하는것 이 다. 제 품의 
두가지 위험한 측면은 그 제품의 자료와 작용들이다. 00 A 는 각이한 모형화기법들을 리 
용하여 자료，작용들 그리 고 그것 들사이 의 호상작용을 리해한다. 분석 과정 에 서 그 제 품에 
관하여 엄어 지는지식은 각이한 방식으로 표현되며 그 매개는 목적하는 제품의 각이한 
측면들을 반영하고 있다. 선도들은 모형화되는 체계에 대한 보다 철저한 리해가 이루어 
짐에 따라서 련속적으로 갱신된다. 00 A 단계의 마감에서 통합된 조사가 제품에 대한 총 
체적인 리해를 제공하게 되는데 이것은 오직 한가지 모형화기법이 도입되였다면 달성하 
기 어려울수 있다. 


12 . 2 . 승강기문제 : 객체지향분석 

00 A 의 단계 들을 한가지 실 례 로서 서 술한다. 승강기문제 는 제11장에 서 처 음으로 
설명하였다. 참고하기 쉽도록 하기 위하여 여 기서 그 문제를 다시 반복한다. 

이 제품은 이층으로 된 어떤 건물에 있는 n 개의 승강기를 조종하기 위하여 설치되게 
된다. 이 문제는 다음과 같은 제약에 따라 m 층사이에서 n 개의 승강기를 움직이는데 
필요한 론리와 관련된 문제이다. 

1. 매 승강기는 m 개의 단추모임을 가지고 있는데 매 층에 하나의 단추가 대응한다. 
단추들은 눌러 질 때 조명 이 켜지며 승강기 가 대 응하는 층을 찾아 가게 된다. 
승강기가 대응하는 층을 찾아 갔을 때 단추의 조명은 꺼진다. 

2. 1층과 마지막층을 제외하고 매층은 두개의 단추를 가진다. 하나의 단추는 
승강기 가 올라 갈것 을 요청하며 다른 하나는 승강기 가 내 려 갈것 을 요청하는 
단추이다. 이 단추들을 누르면 조명 이 켜진다. 승강기가 해당한 층을 찾아 간 
다음 희망하는 방향으로 움직 일 때 조명은 꺼 진다. 

3. 승강기에 아무런 요청도 없을 때 승강기는 문을 닫은채로 현재의 층에 머물러 
있 다. 

00 A 에 서 첫 단계 는 유스케 스 case ) 를 모형 화하는것 이 다. 
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12.3. 유스-케스모형화 ( Use-Case Modelling ) 

유스케스는 구성될 제품의 기능성을 서술한다. 그것은 전체적 인 기능성에 대한 일반 
적인 서술을 제공하여 준다. 그러면 대본들은 마치 객체들이 어떤 클라스의 실례들인것 
처럼 유스케스의 특정한 실례들로 된다. 하나의 유스케스는 쏘프트웨어제품의 클라스들 
과 그 제품의 사용자들사이의 전체적인 호상작용과 관련된다. 하나의 대본은 특정한 객 
체들과 사용자들사이의 하나의 특수한 호상작용들의 모임 이 다. 

승강기문제 에 대 한 유스케 스의 UML 표현을 그림 12-1 에 보여 주었 다. 사용자들과 클 
라스들사이 에 가능한 유일한 호상작용은 사용자가 하나의 승강기 를 호출하려 고 승강기단 
추를 누르거 나 사용자가 승강기 를 어 떤 특정한 층에 세 우려 고 층단추를 누르는것 이 다. 
전체적인 기능에 관한 이러한 일반적서술내에서 많은 서로 다른 대본들을 뽑아 낼수 있 
는데 그 매 대 본들은 호상작용들의 하나의 특정한 모임 을 표현하고 있다. 실례 로 그림 
12-2 는 하나의 표준대 본아을 묘사하고 있다. 즉 우리 가 승강기 가 어 떻게 리용되 여 야 하는 
가를 리해하는 방법 에 대 응하는 사용자들과 승강기 들사이 의 호상작용들의 모임 을 서 술하 
고 있다. 



그림 12-2 는 승강기 (보다 정 확하게 는 승강기단추들과 층단추들)와 호상작용하는 
각이한 사용자들을 주의 깊게 관찰한후 구성 되 였 다. 그림의 15개의 사건들은 사용자 A 와 
승강기체계의 단추들사이의 두개의 호상작용(사건 1과 사건 7) 과 승강기체계의 요소들이 
취하는 작용들(사건 2부터 사건 6까지와 사건 8부터 사건 15까지)을 자세히 서술하고 
象다. 

두개 의 항목 즉《 사용자 A 가 승강기 에 오른다.》와《 사용자 A 가 승강기 에 서 내 린 
다.》는 번호를 붙이지 않았다. 이와 같은 항목들은 본질상 설명에 해당한다. 즉 사용 


시 UML 은 대 본을 표현하기 위한 두가지 류형 의 선도 즉 술차도 (« 방 Mewe diagram ) 와 협 
+ iicollaboration diagram ) 를 제 공한다. 그러 나 이 선도들은 객체지 향분석 보다 객 체지 향설계 에 
서 더 유용하다. 그러 므로 이 선도들에 대 한 론의 는 13.7 에 서 진행한다. 


385 






3. 승강기 가 3층에 도착한다. 승강기 에는 사용자 B 가 
1층에 서 승강기 에 올라 9층 승강기단추를 눌렀 다. 


4. 상승층 단추가 꺼 진다. 

5. 승강기문 이 닫긴 다. 

6. 시 간계수기 가 동작한다. 

사용자 A 가 승강기 에 오른다. 

7. 사용자 A 는 1층승강기 단추를 누른다. 

8. 1층승강기단추가 켜 진 다. 

9. 설정 시 간이 지 나면 승강기문이 닫긴다. 

10. 승강기는 9층으로 움직인다. 

11. 9층승강기단추가 꺼 진 다. 

12. 사용자 B 가 승강기 에 서 내 리 도록 승강기문이 열린 

13. 시 간계수기 가 동작한다. 

사용자 B 는 승강기 에 서 내 린 다. 

14. 설정 시 간이 지 나면 승강기문이 닫긴다. 

15. 승강기는 사용자 A 를 래우고 1층으로 간다. 


그림 12-3. 례외대본 


12.4. 클라스모형화 

이 단계에서 클라스들과 그 속성들이 실체-관련도를 £ 
이 단계 에서 는 클라스의 속성 들만 결정 되 고 방법 들은 결정되 
향설계에서 클라스들에 할당된다. 

전체 적 인 객체지향파라다임의 한가지 특징은 각이한 단^ 
는것이다. 다행히도 객체를 리용하는데서 엄게 되는 리득이 
않는다. 그러 므로 콜라스모형화의 맨 첫단계 즉 콜라스들과 
옳바른것을 얻기가 일반적으로 어렵다는데 대하여 놀라지 밀 

클라스들을 결 정 하는 한가지 방법 은 그것 들을 유스케 스 - 
즉 개 발자들은 표준 및 례외대본들을 포함해서 모든 대 본들 
케스들에서 역할을 노는 요소들을 식별해 낸다. 바로 그림 1 
보클라스들은 승강기단추, 층단추，승강기 , 문 그리 고 시 간계 
는바와 같이 이 후보클라스들은 콜라스모형화기간에 추출되 우 





된다. 경험 없는 개발자는 대본들로부터 너무 많은 후보콜라스들을 추론하려고 할수도 있 
다. 이것은 새로운 콜라스를 추가하는것이 포함되지 말아야 하는 후보콜라스를 제거하는 
것보다 더 쉽기때문에 콜라스모형화에 해로운 영향을 줄것 이 다. 

클라스들을 결정 하기 위한 또 한가지 방법은 CRC 카드 (12.4.2) 인데 이 방법은 개 발자 
들이 령역전문지식을 가지고 있을 때 효과적이다. 그러나 만일 전문가들이 응용령역에서 
경험이 적거나 전혀 없다면 다음절에서 설명한다. 명사추출 (mnm ex / racfew ) 을 리용하는것 
이 현명한 처 사이 다. 


12. 4. 1 . 명사추출 

령역전문지식이 없는 개발자들에게 있어서 한가지 좋은 방법은 다음의 세단계의 
과정을 리 용하여 후보클라스들을 추출하고 그다음 그것들을 세 련하는것 이 다. 

1단계. 간결한 문제정의 제품을 될수록 간단하고 간결하게, 좋기는 하나의 문장으로 
정의한다. 승강기문제에서 이를 위한 한가지 방법은 다음과 같다. 

승강기 와 층에 있는 단추들은 m 층 건물의 n 개 의 승강기 의 움직 임 을 조종한다. 

2단계. 비형식적전략 문제해결에서 비형식적전략으로 대처하기 위하여서는 제약들이 
고려되 여 야 한다. 승강기문제 에 대 한 세 가지 제 약들이 12.2 에 제시되 였 다. 이제 비 형 식적 
전 략은 오히 려 단순단락으로 표시 될 수 있 다. 승강기문제 에 대 한 한가지 가능한 서 술단락 
은 다음과 갈다. 

승강기와 층에 _있는 단추들은 m 층건물의 n 개의 승강기의 움직임을 조종한다. 단추들은 
승강기를 어떤 특정한 층에 세울것을 요청하여 눌렀을 때 조명이 켜전다. 그 요청이 
만족되였을 때 조명은 꺼진다. 승강기에 아무런 요청도 없을 때 승강기는 문을 닫은채로 
현재의 층에 머물러 있다. 

3단계. 전략의 형식화 비형식적전략에서 명사들을 식별(문제범위밖에 놓이는것들을 
배제 하면서)하고 그다음 이 명 사들 을 후보클라스로서 리 용한다. 이제 비형 식적 전략을 
다시 생 성 하는데 이번에는 식별된 명 사들이 다른 서 체 로서 인쇄 된다. 

승강기와 층에 있는 단추들은 mg 건들의 n 개의 승강기의 움직임을 조종한다. 단추들은 승 
강기를 어떤 특정한 ■에 세울것을 요청하며 눌렀을 때 조명이 켜진다. 그 요청이 만족되 
였을 때 조명은 꺼진다. 승강기에 아무런 요청도 없을 때 승강기는 문을 닫은채로 현재의 
층에 머물러 있다. 

여기에는 8개의 서로 다른 명사 즉 단추，승강기, 층, 움직임, 건물, 조명，요청，문이 
있 다. 이 명 사들가운데서 3개 즉 층, 건물, 문은 문제범 위밖에 있기 때 문에 무시 될수 있 다. 
나머지 3개의 명사 즉 움직임, 조명，요청 등은 추상명사들이다. 즉 그것들은《물리적존 
재 를 가지 지 않는 사상 또는 질 로 볼수 있 다》(好公 rW Book Encyclopedia , 2000). 한가지 
유용한 경험은 추상명사들은 좀처럼 클라스에 대응시킬수 없다는것이다. 그대신에 그것 
들은 자주 클라스의 속성으로 된다. 실례로《조명》은 단추의 한가지 속성이다. 이리하 
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여 두개의 명사가 남으며 결국 두개의 후보클라스 Elevator (승강기)와 Button (단추)가 남 
는다 ( UML 습관은 클라스에는 굵은 서체 ( Boldface ) 를 리용하며 클라스이름의 첫 문자는 대 
문자로 쓰는것 이 다.). 

최종클라스선도를 그림 12-4 에 보여 주었다. 클라스 Button 은 그림 12-2 와 12-13 의 
대본들에서 사건 2, 4, 8, 11을 모형화하기 위하여 론리값속성 illuminated 를 가진다. 이 문 

제 는 두가지 류형의 단추를 명 시하며 따라서 Button 의 두개 부분클라스가 정 의된다. 즉 

Elevator Button 과 Floor Button (열 린 삼각형 은 UML 에서 계승을 의 미 한다.)이 정의 된 다. 
매 Elevator Button 과 Floor Button 은 Elevator 와 정 보를 교환한다. 클라스 Elevator 는 론리 
값속성 doors open 을 가지 는데 그것 은 두개의 대 본에서 사건 5, 9, 12, 14를 모형 화한다. 

유감스럽게도 출발이 잘되지 못하였다. 실지 승강기 에서 단추들은 승강기와 직접 정 
보를 교환하지 않는다. 만일 어 떤 특수한 요청 에 의하여 어 느 승강기 를 보내 야 하는가만 
을 결정 하기 위 하여서 는 일정한 종류의 승강기 조종기 가 요구된다. 그러 나 문제 설정 에서 
는 조종기에 대하여 전혀 언급하지 않고 있으므로 명사추출단계에서 그것은 콜라스로 선 

택되지 않았다. 달리 말하면 클라스후보를 찾기 위한 이 절의 방법 은 하나의 출발점을 주 

고 있지 만 그이 상의 것 은 기 대하지 말아야 한다. 



그림 12-4. 믈라스도의 첫번째 반복 

Elevator controller 를 그림 12-4 에 추가하여 그림 12-5 를 엄는다. 이것은 확실히 합 
리적이다. 그러므로 임의의 시각에 지어는 통합단계만큼 늦어서도 콜라스모형화에로 돌 
아 갈수 있 다는것 을 념두에 두면서 이 시 점 에서 3단계(동적모형화)에 로 이 행하는것 이 합 
리 적 인것 같다. 그러 나 동적모형화에 로 나가기 전에 콜라스모형 화를 위한 한가지 다른 기 
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법을 고찰한다. 



그림 12-5. 콜라스도의 두번째 반복 

1 2. 4. 2. CRC 카드 

오래 동안 클라스-책 임 -협 동사 沙 - co//a6ora"on(CRC)) 카드가 객 체 지 향분석 
단계 에 서 리 용되 여 왔다 [Wirfs-Brock, Wilkerson, and Wiener, 1990] . 매 클라스에 대 하여 
쏘프트웨 어 개발림 은 클라스의 이 름, 그것 의 기 능(책 임 )，그 기 능을 달성 하기 위하여 호출 
하는 다른 클라스들의 목록(협 동)을 보여 주는 하나의 카드를 작성한다. 이 방법 은 그다 
음에 확장되였다. 첫째로 하나의 CRC 카드는 흔히 자연언어로 표시된 클라스의 《책임》 
이 아니라 클라스의 속성과 방법들을 명백히 포함한다. 둘째로 기술이 변화되였다. 카드 
를 리용하는것 대 신에 일부 개 발기 업 체 들은 부전지 ( Am /- 均기 록장에 콜라스들의 이 름을 
불인다. 개 발기 업 체 는 부전지 기 록장을 흰판우에 서 돌리 며 협 동을 지 적 하기 위 하여 부전 
지기 록장들사이 에 선 이 그어 진 다. 

현재 이 전체 공정 은 자동화될 수 있 다. 체 계구성 ( 切께 m Architect )^- 같은 CASE 도구 
들은 화면상에 서 CRC 《 카드》들을 창조하고 갱 신하기 위한 모둘들을 포함하고 있 다. 

CRC 카드의 우점 은 다음과 같다. 개발림 이 CRC 카드를 리 용할 때 개 발성 원들사이의 
호상작용은 어떤 클라스안에서의 오해 나 부정확한 마당들 즉 속성 이나 방법들을 뚜렷하 
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게 할수 있다. 또한 클라스들사이의 호상관계는 CRC 카드가 리 용될 때 뚜렷해 진다. 

의 특별히 강력한 기 법은 림성 원들속에 카드를 배포하는것 이 다. 그러 면 그들은 자 7 
클라스책 임 을 수행하게 된 다. 이 를 테 면 누군가가 《 나는 Date 클라스인데 나의 책 임 
새로운 날자객체를 창조하는것 이 다.》라고 말할수 있다. 그러면 다른 림 성원은 자 7 ' 
Date 클라스에서 추가적인 기능이 요구된다고 말할수 있다. 즉 어떤 날자를 습관적인 
식으로부터 하나의 옹근수 이를테면 1990년 1월 1일로부터의 일수로 변환하는것과 걸 
기능，결국 임의의 두 날자사이의 일수를 대응하는 두 옹근수를 더는것으로써 쉽게 겨 
할수 있도록 하는 기능을 요구할수 있다(다음의 《 알고 싶은 문제》를 보시오.). 결 
CRC 카드의 책임을 수행하는것은 클라스선도가 완전하고 정확하다는것을 검증하기 후 
효과적 인 수단으로 된다. 

알고 싶© 용제 

1999 년 2 월 21 일과 2001 년 8 월 10 일사이의 일수를 어떻게 찾아 내겠는가이 i 한 덜 
기 연산은 리 자지불계산이 나 미 래의 현금류출입 의 현재값결정 과 갈은 많은 재정계 안들에 
서 요구된다. 이것을 위한 유용한 방법은 매 날자를 어떤 옹근수 즉 어떤 규정된 t 발날 
자로부터의 일수로 변환하는것이다. 문제는 바로 리용할 출발날자를 일치시킬수 표다는 
것이다. 천문학자들은 율리우스날자，,기원전 4713 년 1 월 1 일의 낮 12GMT (그리 H 치표 
준시 간)로부터 의 일 수를 리용한다. 이 체 계 는 ,1582 년에 조세프 스를리저 (Joseph S aliger) 
에 의하여 발명되 였는데 그 fe 이것을 자기 아버지 율리 우스 스를리저 (Julius Caesar 
Scaliger) 를 위 하여 명명 하였다(왜 기원전 4 기 3 년 1 월 1 일을 선택 하였는가를 실지 : 알고 
싶 다면 [I 犯 NO, 200 이에 문의 하시 오) . 릴 리 안 (Lilian) 날자는 1582 년 10 월 15 일 즉 료마법 
왕 그레고러 8 세 (Gregory X ID) 가 도입 한 그레고리력의 첫날로부터의 일수이다. 릴 다 안날 
자는 그레고리력개혁의 기본제안자인. 루이지 릴리오 (Luigi Lilio) 를 위하여 명명 ᅵ였다. 
릴리오는 윤년 법 칙 을 비 롯한 그레 고리 력 과 관련된 많은 알고리 듬들을 개 발하는 c 서 책 
임 적 역할을 하였 다. 

쏘프트웨 어 방면 에 서 고찰하면 ANCI COBOL85 의 본질 적 기 능들은 옹근수날자의 i 발날자 
로서 16 이년 1 월 1 일을 리 용하고 있 다. 그러나 거의 모든 표처리 프로그람 Csprea 쇼;! e < s ) 들은 
Lotus 1-2-3 의 안내를 따라 1900 년 1 월 1 일을 리용하고 있다. 

CRC 카드의 약점 은 이 방법 이 일 반적 으로 림 성 원들이 련관된 응용령역 에 상당한 
험 을 가지 고 있지 않는 한 클라스들을 식 별 하기 위한 좋은 방법 으로 되 지 않는다는것 
다. 한편 일단 개발자들이 많은 클라스들을 결정하고 그것들의 책임과 협동에 좋은 老 
을 가지고 있다면 CRC 카드는 그 공정을 완성하고 모든것이 정확하다는것을 확인하기 




1 2. 5. 동적모형화 

동적 모형 화의 목적은 매 클라스에 대 하여 상태도(해?/£ diagram ) 즉 유한상태기계 에 
류사한 목표제 품에 대 한 서 술을 생 성하는것 이 다. 우선 클라스 Elevator Controller 를 
고찰하자. 간단하게 하기 위하여 한대 의 승강기만 고찰한다. Elevator Controller 에 대 한 
상태도를 그림 12-6 에 보여 주었다. 

표시 법 은 11.6 의 유한상태 기계의 표시 법 과 약간 류사하지 만 한가지 중요한 차이 가 
있다. 제11장에 제시된바와 같이 FSM 은 형식적기법의 한가지 실례이다. 상태이행도 
그자체는 작성될 제품에 대한 완전한 표현이 아니다. 그대신에 모형은 식 (11.2) 로 주어 
지는 형식의 이행규칙들의 모임이다. 즉 


current state and event and predicate => next state. 

형식성은 수학규칙들의 모임 형태로 모형을 제시함으로써 달성된다. 

반대로 UML 상태도의 표현은 약간 덜 형식적이다. 상태기계의 세개의 측면들(상태, 
사건, 술어)은 UML 선도우에 분포된다. 실례로 그림 12-6 에서 상태 Go into Wait State 는 
만일 현재의 상태 가 Elevator Event Loop 이 고 술어 [elevator stopped , no requests pending ] 
이 옳다면 입력된다 ( UML 술어는 그림 12-6 에 보여 준것처럼 중괄호안에 나타난다.). 상태 
Go into Wait State 가 입력 되였을 때 작용 Close elevator doors after timeout 가 수행 되 게 
된다. OOA 현재판은 준형식적(도형)기법이며 따라서 상태도의 형식성의 본질적결여는 문 
제 로 되지 않는다. 그러 나 객체지향파라다임 이 성 숙될 때 보다 형 식적 인 판본이 개 발되 
고 대응하는 동적모형들은 유한상태기계에 좀 더 가까와 질것 갈다. 

그림 12-6 의 상태도와 그림 11-4 부터 11-16 까지 의 STD 의 등가성 을 보기 위하여 
각이한 대 본들을 고찰하자. 실례 로 그림 12-2 의 대 본의 첫 부분을 고찰하자. 먼저 
사용자 A 는 3층에서 상승층단추를 누른다. 만일 층단추가 조명이 켜지지 않았다면 
그림 11-15 와 그림 12-6 의 상태 Process Request 에 따라 그 단추는 필요할 때 켜진다. 
상태도의 경우에 다음상태는 Elevator Event Loop 이 다. 

그다음 승강기는 3층에 접근한다. 먼저 STD 방법을 고찰하자. 그림 11-16 에서 승강 
기 는 상태 S ( U , 3) 에 로 간다. 즉 승강기 는 올라 가려 는 3층에 서 멈추어 선 다(한대 의 승 
강기뿐이라는 단순한 가정을 하였기때문에 그림 11-16 에 있는 인수 e 는 여기서 생략한 
다.). 그림 11-5 로부터 승강기가 도착할 때 층 단추는 꺼진다. 이제(그림 11-6) 문이 닫 
기 고 승강기는 4층을 향하여 움직 이 기 시 작한다. 

그림 12-6 의 상태도에 돌아 와서 승강기가 3층에 접근할 때 일어 나는 상황을 고찰 
하자. 승강기는 움직 임 상태 에 있기때문에 입력되는 다음상태는 Determine if Stop 
Requested 이 다. 요청은 접수되며 사용자 A 는 승강기 를 여 기서 멈 출것을 요청 하였기때 문 
에 다음상태 는 Stop at Floor 이 다. 승강기 는 3층에 서 멈 추어 서 고 문이 열린 다. 3층 승강 
기 단추가 눌리워 지지 않았으므로 다음 상태는 Elevator Event Loop 이 다. 

사용자 A 는 승강기 에 오르고 7층 단추를 누른다. 다음상태는 다시 Process Request 
이고 다음은 다시 Elevator Event Loop 이 다. 승강기는 멈 추어 섰고 두가지 요청 이 해결되 
지 않은채로 있으므로 다음상태는 Close Elevator Doors 이며 문은 설정시간이 지나면 닫 
긴다. 사용자 A 가 3층단추를 눌렀기때문에 Floor Button Off 가 다음상태로 되며 층단추 
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없 다. 보다 정 확하게 는 대 본들의 특정한 사건들은 일 반화되 였 다. 실례 로 그림 12-2 의 
대 본의 첫 사건 즉 《사용자 A 는 3층에서 상승층단추를 누른다.》를 고찰하자. 이 
특정한 사건은 어떤 임의의 단추를 누르는것으로 일반화된다. 그러면 두가지 가능성 이 
존재한다. 즉 그 단추가 이 미 켜 졌든가(이 경 우에 는 아무 상황도 일 어 나지 않는다.) 그 
단추가 켜 지지 않았든가(이 경우에는 사용자의 요청 을 처 리 하기 위한 작용이 취 해 져 야 
한다.)이다. 

이 사건을 모형 화하기 위 하여 Elevator Event Loop 상태 가 그림 12-6 에 그려 진다. 
이미 조명이 켜진 단추의 경우는 그림 12-6 의 웃단 왼쪽 구석에 있는 경계상태 [button 
pushed , button unlit ] 로서 아무것도 하지 않는 고리 로 모형 화된다. 다른 경우에 조명 이 꺼 
진 단추는 경계상태 [button pushed , button unlit ] 로서 표식 붙은 상태 Process Request 로 
이 끌어 가는 화살표로 모형화된 다. 대 본의 사건 2로부터 작용 Turn on button 이 이 상태 
에서 요구된다는것은 명백하다. 더우기 임의의 단추를 누르는것과 관련한 사용자의 작용 
목적 은 한대 의 승강기 를 요청하는것 이 며 따라서 작용 Update requests 가 또한 상태 Proc 
ess Request 에서 수행 되 여 야 한다. 

이때 대본의 사건 3. 승강기가 3층에 도착한 다를 고찰하자. 이것은 층사이에서 움직이는 
임의의 승강기라는 개념으로 일반화되였다. 승강기의 이동은 경계상태 [elevator moving in 
direction d , floor f is next ] 와 상태 Determine if Stop Requested 로 모형 화된 다. 그러 나 두 
개 의 가능성 이 존재한다. 즉 승강기 를 유에서 멈 추려 는 요청 이 든지 그러한 요청 이 없든 
지 이 다. 앞의 경 우에 경 계 상태 [no request to stop at floor 幻에 대 응하여 승강기 는 d 방향으 
로 한층 더 계속 움직여야 (Continue Moving) 한다. 후자의 경우에 (경계상태 [user has 
requested stop at floor 인에 대응하여) 그림 12-2 의 대본으로부터 승강기를 멈추 (Stop 
elevator ) 고(사건 3으로부터) 그다음 문을 열고 시간계수기를 동작 (Open doors and start 
timer ) 시키 는것 (사건 5와 6으로부터 )이 필 요하다는것 은 명 백하다. 또한 Precess Request 상 
태의 경우와 류사하게 상태 Stop at Floor 에서 요구를 갱 신 (Update requests ) 하는것 이 필요 
하다는것 이 명 백 하다. 마지 막으로 대 본의 사건 4를 일 반화하는것 은 만일 승강기단추가 
켜 졌으면 그것 을 꺼 야 한다는것을 실현하는데 로 이끌어 간다. 이 것은 상태 Elevator Bu 
tton Off (그림 12-6 의 하단 왼쪽에 있는 상태)와 이 상태를 표현하고 있는 경우의 2개의 
경 계 상태 들에 의하여 모형화된 다. 

그림 12-2 의 대본의 사건 9 를 모형화하면 상태 Close Elevator Doors 가 생성된다. 사 
건 10 을 모형 화하면 상태 Process Next Request 가 생 성 된다. 그러 나 상태 Go into Wait 
State 와 경 계 상태 [no requests pending , doors closed ] 에 대 한 요구는 다른 대 본의 사건 즉 
사용자가 승강기에서 내리고 조명이 켜져 있는 단추가 하나도 없는 사건을 일반화하여 
유도된 다. 

다른 클라스들에 대 한 상태도는 상대적으로 단순하므로 련습문제 로 남겨 둔다(문제 12.1). 

1 2. 6. 객체지향분석단계에서의 시험 

이 시점에서 객체지향분석공정의 세개의 모형이 완성될수 있다. 다음단계는 지금까 
지의 OOA 를 검토하는것이다. 이 검토의 한가지 요소는 12.4.2 에서 제안한것처럼 CRC 카 
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드를 리용하는것이다. 

따라서 매 콜라스 Button, Elevator Button, Floor Button, Elavator, Elevator 
Controller 에 대하여 CRC 카드가 기입된다. 그림 12_7에 보여 준 Elevator Controller 에 
대한 CRC 카드는 그림 12-5 의 클라스도와 그림 12-6 의 상태도로부터 연역된다. 

보다 자세히 고찰하면 Elevator Controller 의 책 임 ( RESPONSIBILITY ) 은 Elevator 
Controlled 대한 상태도에 있는 모든 작용들을 렬거함으로써 엄어 졌다(그림 12_6). 
Elevator Controller 의 협동 ( COLLABORATION ) 은 그림 12_5의 클라스도를 시험 하고 콜라 
스 Elevator Button, Floor, Button, Elevator 가 클라스 Elevator Controller 와 호상작용한다 
는것을 기록함으로써 결정되였다. 

이 CRC 는 객체지향분석의 첫 반복과 함께 두가지 중요한 문제들을 강조하고 있다. 
먼저 책임 1. 승강기단추를 켠다를 고찰하자. 이 지령은 객체지향파라다임에서 총적으로 
어울리지 않는다. 책 임구동설계의 관점 (1.6) 으로부터 클라스 Elevator Button 의 객체들은 
그 단추들을 켜거나 끄는데 책임이 있다. 또한 정보은페의 관점으로부터 Elevator 
Controller 는 어떤 단추에 조명을 켜거나 끄는데 필요한 Elevator Button 의 내부에 관한 
지식을 가지지 말아야 한다. 


클라스 

_ Elevator Controller _ 

책 임 

1 승강기단추를 견다. 

2 승강기단추를 끈다. 

3 층단추를 견다. 

4 층단추를 끈다. 

5 승강기를 한 층 우로 이동시킨다. 

6 승강기를 한 층 아래로 이동시킨다. 

7 승강기문을 열 고 시 간계 수기 를 동작시 킨 다. 

8 설정 시 간이 지 나면 승강기문을 닫는다. 

9 요구를 검사한다. 

10 요구를 갱신한다. _ 

협 력 

1 믈라스 Elevator Button 

2 콜 라스 Floor Button 

3 클라스 Elevator _ 


그림 12-7. 믈라스 Elevator Controller 를 위한 
CRC 카드의 첫번째 반복 

정확한 책 임은 다음과 같다. 즉 승강기단추에 불을 켜기 위하여 Elevator Button 에 통보 
를 보내는것이다. 그림 12-7 에 있는 책임 2부터 6까지에 관하여 이와 류사한 변경들이 


395 





필요하다. 이 6개의 변경들은 그림 12-8 Elevator Controller 에 대한 CRC 카드의 두번째 
반복에서 반영된다. 

두번째 문제는 클라스가 검 열되 였다는것 이 다. 책 임 7. 승강기문을 열고 시간계수기를 동 
작시킨 다를 고찰하자. 여기서 중요한 개념은 상태 ( sto / e ) 에 대한 개념이다. 어떤 클라스의 
속성들을 때때로 상태변수 Oto/e w / aWe ) 라고 부론다. 그 리 유는 대부분 객체지 향실천들 
에서 제품의 상태 가 각이한 요소객체들의 속성값에 의하여 결정되 기때 문이 다. 상태도는 
유한상태기계와 공통적인 많은 특성을 가지고 있다. 따라서 상태의 개념이 객체지향파라 
다임에서 중요한 역할을 논다는것은 놀라운 일이 아니다. 이 개념은 어떤 요소가 클라스 
로 모형화되 여 야 하는가를 결 정하는것 을 돕는데 리용될 수 있 다. 만약 문제 로 되 는 요소가 
실현의 실행기간에 변화된 상태를 가진다면 그것은 아마도 클라스로 모형화되여야 한다. 
명백히 승강기의 문은 하나의 상태(열거나 닫는)를 가지며 그러므로 Elevator Doors 는 하 
나의 콜라스로 되여야 한다. 

Elevator Doors 가 콜라스로 되여야 할 또 하나의 리유가 있다. 객체지향파라다임은 상태 
가 객체내에서 은폐되여 허가되지 않은 변경으로부터 보호되도록 한다. 만일 하나의 Elevator 
Doors 객체가 있다면 승강기문을 열거나 닫을수 있는 유일한 방도는 이 Elevator Doors 객체에 
통보를 보내는것이다. 제정되지 않은 시간에 승강기문을 열거나 닫으면 엄중한 사고가 발생 
할수 있다(즉 다음의 《 알고 싶은 문제》를 보시오.). 그러므로 일정 한 류형의 제품들에 대 하 
여 7장과 8장에서 렬거된 객체의 기타 우월성에 안정성제약을 추가하여야 한다. 


알고 싶 e @제 

몇년전에 내가 한 건물최! 10층에서 조바심이 나서 승강기를 기다리고 있었 p 문이 
열리고 ' J | 는 앞으로 걸음을 떼기 시작하였다. 그러나 승강기 fe 계기에 없었다. 내: . 승강 
기통로에로 걸어 가려다가 멈춰 서게 된것은 앞에서 완전한 어둠을 보았기때문이ᄄ 본능 
적으로 무엇인가 잘못 되였다는것을 깨달았기때문이 다. 

아마 승강기조종체 계 가 객체지향파라다임 을 리용하여 개 발되 였다면 10층에서:성 부적 
당한 문열기와 같은 일은 없었을수도 있었다. 


Elevator Doors 를 클라스에 넣는다는것은 그림 12-7 에 있는 책 임 7과 8이 책 임 1부 
터 6까지 와 류사하게 변경 될 필요가 있다는것 을 의 미한다. 

즉 문을 열거 나 닫기 위 하여 Elevator Doors 에 통보들을 보내 야 한다. 그러 나 추가적 
인 복잡성이 생긴다. 책임 7은 승강기문을 열고 시간계수기를 동작시키라 이다. 이것은 두개의 
개 별적 인 책 임 으로 갈라야 한다. 한가지 통보가 승강기 문을 열기 위하여 Elevator Doors 
에 보내져 야 한다. 그러 나 시 간계수기는 승강기조종기 Elevator Controller 의 한 부분이며 
그렇 기 때 문에 시 간계 수기 를 동작시 키 는것 은 Elevator Controller 그자체 의 책 임 이 다. 
Elevator Controller 에 대한 CRC 카드의 두번째 반복(그림 12-8) 은 이와 같은 책임의 분리 
가 성 과적 으로 수행 되 였 다는것 을 보여 주고 있 다. 그림 12-7 의 CRC 카드에 의해 강조된 
두개 의 중요한 문제 외 에 도 Elevator Controller 의 책 임 check requests 와 update requests 들 


396 









그림 12-9. 콜라스도의 세번째 반복 


1. 사용자 A 는 3층에서 상승층단추를 눌러 승강기를 요청한다. 

사용자 A 는 7층으로 가려고 한다. 

2. 층단추. 숨강기 조종기 에 층 단추가 눌러 졌다는것 을 통보한다. 

3. 승강기 조종기 는 상승층 단추가 켜 지 도록 상승층 단추에 통보를 보낸다. 

4. 승강기조종기는 승강기가 3층으로 이동하도록 승강기에 일련의 통보들을 
보낸다. 승강기 에는 사용자 B 가 있는데_ .그는 1층에서 승강기 에 올라 9층 
승강기단추를 눌렀 다. 

5. 승강기조종기는 상승층단추가 꺼지도록 상승층단추에 통보를 보낸다. 

6. 승강기 조종기 는 '승강기 문을 열 도록 승강기 문에 통보를 보낸 다. 

7. 승강기조종기는 시 간계수기를 동작시킨다. 

사용자 A 가 승강기 에 오른다. 

8. 사용자 A 는 7층 승강기 단추를 누른다. 

9. 승강기 조종기 는 승강기단추가 눌러 졌 다는것 을 통보한다. 

10. 승강기조종기 는 7층승강기단추가 켜 지 도록 그 단추에 통보를 보낸 다. 

11. 승강기조종기는 설정시간이 지나면 승강기문을 닫도록 승강기문에 통보 
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그림 12-10. 표준대본의 두번째 반복 






12. 승강기조종기 는 승강기 가 7층으로 이 동하도록 승강기 에 일 련의 통보들 
을 보낸다. 

13. 승강기조종기는 7층 승강기 단추가 꺼지도록 그 단추에 통보를 보낸다. 

14. 승강기조종기 는 사용자 A 가 승강기 에 서 내 리 도록 승강기문을 열기 위 
하여 승강기문에 통보를 보낸다. 

15. 승강기조종기는 시간계수기를 동작시 킨다. 

사용자 A 는 승강기 에 서 내 린 다. 

16. 승강기 조종기 는 설정 시 간이 지 나면 승강기문을 닫도록 승강기문에 통보 
를 보낸다. 

17. 승강기 조종기 쫏 사용자 B 를 래우고 승강기 가 9층으로 이 동하도록 승강 
기에 일련의 통보들을 보낸다. 


그림 12-10. 표준대본의 두번째 반복(계속) 


1 2. 7. 객체지향분석단계를 위한 CASE 도구 

객체지향분석 에서 선도가 노는 역 할을 생 각하면 많은 CASE 도구들이 개 발되 여 객체지 
향분석을 지원하고 있다는것은 놀라운 일이 아니다. 그 기본형식에서 이와 같은 도구는 본 
질상 매 모형 화단계 를 쉽 게 수행할수 있게 하는 그리 기 도구이 다. 보다 중요하게 는 손으로 
그린 도형을 변경시키려고 하는것보다 그리기도구로 작성된 선도를 변경시키는것이 훨씬 
더 쉽다. 결국 이러한 류형의 CASE 도구는 객체지향분석의 도형측면을 지원하고 있다. 

더우기 이러한 류형의 일부 도구들은 모든 련관된 선도들뿐아니라 CRC 카드도 그린 
다. 이 도구들의 우점은 기초를 이루는 모형에 대한 변경 이 영향을 받은 모든 선도들에 
자동적으로 반영된다는것이다. 결국 각이한 선도들은 순전히 기초를 이루는 모형에 대한 
서로 다른 관점들로 된다. 

한편 일부 CASE 도구들은 객체지향분석뿐아니라 객체지향생명주기의 나머지 상당한 부 
분들을 지원한다. 현재 이 모든 도구들은 사실상 UML 을 지원하고 있다 [ Rumbaugh , Jacobson , 
and Booch , 1999]. 이 와 같은 도구들의 실례들은 Rose and Together 를 포함하고 있다. 

1 2. 8. 항공음식전문회사 실례연구 : 

객체지향분석 

객체지향분석은 세개의 단계 유스-케스모형화，클라스모형화，동적모형화로 이루어 
진다. 이 단계들은 첫단계 즉 유스-케스모형화로부터 시작하여 반복적으로 수행된다. 항 
공음식 전문회 사 신속원형 의 주차림 표(부록 3 또는 4) 는 유스케 스의 목록을 생성한다. 이 
것 들은 또한 상당히 많은 품을 들여 서 10.14 의 요구들로부터 직 접 연역 될 수 있 었다. 

어떤 예약을 하기 위한 유스케스를 그림 12-11 에 보여 주었다. 이 유스케스선도에 대하 
여 표준 및 례외대본들이 요구된다. 한가지 방법은 개별적인 표준 및 례외대본들을 구성하는 
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그림 12-12 에서 사건 1로 표시된다)을 선택하면 비 행정보(사건 4와 
뉴 9)，특별식사정보(사건 6과 7)，승객정보(사건 2와 3) 에 대한 요청。 
좋지 못한 순서 로 정 보를 요청하며 예 약에 대 한 지 불이 생 략되였 1 ^ 
斗. 요청 들을 재배렬하고 지불부분을 추가하여 그림 12-12 의 사건 
경 하였 다. 대 본의 마지 막 3개 의 사건들은 대 본의 표준부분을 완성농 

대 안은 표준사건들에 대 하여 작업하는 동안 연역 되 였 다. 신속원형 
찾는것은 좋은 생각이 아니 다. 신속원형은 포함하고 있는 코드를 J 
조급하게 구성되여서 그림 12-12 에 있는 사건 기부터 H ) 까지와 ^ 
없다. 

서 를 되 돌려 보내 고 조사하기 위한 유스케 스를 그림 12-13 에 보여 
1■는 확장대본은 그림 12-14 에 보여 주었다. 이 대본의 사건 3은 신수 
으로부터 엄 어 졌 다. 사건 1과 2는 그다음 그 대 본을 완성 하기 위하 o 
본에서와 마찬가지로 4개의 가능한 대 안들이 표준사건들에 대하여 크 





기타 유스케스들(특별식사목록의 참조와 선택, 특별식사의 수송，《저염식사》보고서 
보기, 《퍼센트통계》보고서보기, 《오르지 않은 식사》보고서보기，《저질식사》보고서 
보기)은 그 개별적인 확장대본들과 류사하다. 그러므로 간결하게 하기 위하여 그것들을 
여기서 생략한다. 

두번째 단계 는 클라스모형 화 ( c/a 사 moc / e //« g ) 이 다. 이 단계 의 목적 은 클라스들을 추출 
하고 클라스의 속성 들을 찾고 그것 들의 호상관계 와 호상작용들을 결정하는것 이 다. 이 것 
은 대본 또는 CRC 카드가 아니라 12.4 의 세단계 명사추출방법을 리용하여 수행되였다. 1 
단계 는 제 품을 될수록 간단하게 명 확하게 단일 문장으로 정 의하는것 이 다. 항공음식전문회 
사의 경우에 이를 위한 한가지 가능한 방법은 다음과 갈다. 

를퓨터화된 체계가 특별식사프로그람의 효과성을 고려하여 정보를 제공하기 위하여 요 
구된 다. 

2단계에서 비형식적전략이 단일단락으로 작성된다. 한가지 가능한 단락은 다음과 같다. 

보고서가 특별식사프로그람의 효과성을 문서화하기 위하여 생성되게 된다. 이 보고서들은 
비행기 에 오른 식사，승객 이 오른 비행기，승객들의 이름과 주소，식사질, 저염식사질과 
관련되여 있다. 

3단계에서 이 단락안에 있는 명사들이 식별되여 다음과 같은 단락이 생성된다. 

보고서가 특별식사 프로 그람의 효과 성을 문서화하기 위하여 생성되게 된다. 이 보고서들은 
비행기에 오른 식사와 승객들의 비행 기 탑승의 퍼센트, 승객들의 이 ■과 주소, 식사질, 
저염식사질과 관련되여 있다. 

명사들은 보고서 ( report ), 효과성 ( efficacy ), 프로 그람 ( program ), 퍼센트 ( percentage ), 승객 
( passenger ), 이름 ( name ), 주소 ( address ), 질 ( quality ) 이다. 효과성 ( efficacy ), 프로그람 ( program ), 
퍼센트 ( percentage ), 탑승 ( boarding ), 질 ( quality ) 은 추상명사들이며 그렇기 때문에 클라스로 될 
것 같지 않다. 이 름 ( Name ) 과 주소 ( address ) 는 명 확히 승객 ( passenger ) 의 속성 들이 다. 주어 진 
비행기에 서 특별식사의 존재와 결여는 중심적 인 론점 이 다. 명백치 않는것은 식사 ( meal ) 
그자체 또는 비 행 ( flight ) 그자체 가 콜라스로 되 겠는가 하는것 이 다. 콜라스를 추가하는것 
은 삭제하는것보다 일반적 으로 더 쉽기때 문에 적 어도 첫번째 반복에서는 이 두 명 사를 
제쳐 놓는것 이 더 좋았을것 이 라고 느껴 진다. 이로부터 두개의 명사들이 남게 되며 따라 
서 두개의 후보클라스 즉 Report 와 Passenger 가 생성된다. 최종적인 클라스도의 첫 반복 
은 그림 12-15 에 보여 주었 다. 이 그림 은 네개의 부분콜라스를 포함하여 두개 의 후보클 
라스를 반영하고 있는데 매 보고서에 하나의 부분클라스가 할당된다. Report 콜라스는 네 
개의 보고서 에 공통인 마당 즉 시 작날자와 마감날자를 포함한다. 매 부분콜라스는 그 보 
고서 에 특정 한 마당들을 포함한다. 

이 클라스도에 여 러 가지 문제 들이 존재한다. 

1. 각이한 보고서들을 인쇄하기 위하여 요구되는 정보를 계산하자면 매번 비행할 때 
마다 자료가 요구된다. 실례로 특별식사를 주문한 비행기에 오른 승객들의 퍼센트 
를 결정하기 위하여서는 자료를 비행기안에 조직해 넣어야 한다. 

2. 매 보고서는 여러개의 비행기록들을 호출하여야 하며 매 비행은 여러명의 승객들 
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을 가진다. 

3. 10.14 은 그림 12-15 에 반영된것처럼 네개의 번호 붙은 보고서를 명시하고 있다. 그러 
나 첫번째 번호 붙은 보고서는 세개의 개별적인 보고서들로 이루어 진다. 그러므로 클 
라스도는 Report 콜라스의 6 개 (4 개 가 아니 라)의 부분클라스들을 반영 하여 야 한다. 



그림 12-15. 항공음식 전문회 사제 품을 위한 믈라스도의 첫 번째 반복 

이 사건들이 그림 12-16 의 콜라스도에 반영된다. 거기에는 실지로 Report 의 6 개의 
부분쿨라스가 있 다. 더 우기 Report 와 Flight Record 사이 에 는 1대 n 관계 가 존재 한다. 
이것은 매 보고서가 여러 비행기들로부터 얻은 정보들을 포함하고 있다는것을 반영하고 
있 다. 결 국 Flight Record 옆 에 열 려 있 는 다이 야몬드표식 은 집 합을 의 미 하여 (7.7) 
Passenger 옆의 * 기 호는 1대 n 관계 를 의 미 한다. 즉 매 비 행 기록은 여 러 개의 승객 기록들을 
포함한다. 이 기록들은 Flight Record 의 요소들로써 모형 화되 였다. 그대신 단순성과 명 백 
성 을 위 하여 Passenger 콜라스는 독립 적 인 실체 로서 취 급된다. 마당(열쇠) passenger 正)는 
주어 진 Passenger 를 대 응하는 Flight Record 와 련관시 키 기 위 하여 리 용된 다. 

클라스도의 첫번째 반복은 무엇때문에 그렇게 틀렸는가? 이 문제의 한가지 원인은 
Flight 를 하나의 후보속성 으로 포함하지 않도록 결정한데 있 다. 누구나 정 상적 인 기 준을 
가지 고 있는데 이때 에 는 Flight 도 Meal 도 초기 후보콜라스로 선택하지 않은데 원인이 
있는것 갈다. 
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적한바와 같이 콜라스를 추가하기는 쉽지만 
L 첫번째 반복에 서 두개 의 후보클라스만 선로 


.고서부분클라스들만 병합하기로 한 결정을 정 당화하는것은 그리 쉽지 않 
원형(부록 3 또는 부록 2) 은 6개의 보고서를 포함한다. 한편 이것은 부차적 
9게 해결된다. 

'복의 부적 당성을 념려하는것(그림 12-15) 대신에 일단 보고서에 대한 자료가 
이 아니라 비행에 기초하여 조직되여야 한다는것을 깨달았으면 두번째 반복 


















제품이 아니라 하나의 클라스에 관계하고 있다. 그러나 항공음식전문회사제품의 클라스 
들이 상태로부터 상태에로 옮겨 가지 않기때문에 그림 12-17 과 갈은 상태도는 항공음식 
전문회 사제품에 보다 적 합하다. 이것 으로 객체지향분석 이 완성된듯 하다. 그러 므로 그것 
을 검 토하여 야 한다. 의뢰 자도 개발림 도 UML 선도들의 모임 을 적 당한 명세서 로 기꺼 이 
받아 들이려 하지 않는다. 결국 11.1 에서 지적한바와 같이 명세서는 의뢰자와 개발자들사 
이의 계 약서 이다. 따라서 00 A 가 완성된후에 보다 습관적 인 명세서 가 작성되 여 야 한다. 
이 문서 는 부록 5에 있는 대 부분의 자료들과 아주 류사하기 때 문에 이 실 례연구에 서 는 생 
략한다. 구조화된 파라다임 이 항공음식 전문회 사제 품의 명세 서 에 리용되 였을 때 와 마찬가 
지 로 (11.15) 이 시 점 에서 쏘프트웨 어프로젝 트관리계 획 이 작성된다. 부록 6은 소규모 (3 명) 
쏘프트웨 어개 발기 업체 가 항공음식전문회 사제품을 개 발하기 위한 쏘프트웨 어관리 계 획을 
포함하고 있다. 이 계획은 IEEE SPMF 형식에 준하고 있다. 

1 2. 9. 객체지향분석단계에서의 난관 

객체지향분석 은 명세작성단계 에 대 한 한가지 특정한 방법 이 다. 그러므로 11. 16에서 
서술된 명세작성단계의 일 반적난관들은 객체지향분석 에 동등하게 적 용된다. 특히 11. 16에 
서 제시된 두번째 난관은 명세서(《무엇》)와 설계(《어떻게》)사이의 계선을 혼돈하기 
쉽다는것이다. 이러한 위험성은 객체지향분석의 경우에 특별히 심하게 제기된다. 

1.6 에서 서술한바와 같이 객체지향분석으로부터 객체지향설계에로의 이행은 고전적 
파라다임작성 에 서 명세작성단계 로부터 설계 단계에 로의 이 행보다 훨 씬 원활하다는것 을 상 
기 하자. 고전적파라다임작성 에 서 설 계 단계 의 초기 과제 는 제 품을 모둘들로 분해하는것 이 
다. 반대 로 클라스들 즉 객체지향설계 단계의 《 모둘들》은 객체지향분석단계 에서 추출되 
여 객체 지향설계 단계에서의 세 련을 위하여 준비된다. 00 A 단계 에서 벌써 클라스들이 출 
현하는것은 00 A 를 오래동안 리용하려는 유혹이 극히 강할수 있다는것을 의미한다. 

실례 로 클라스에 로 방법 들의 병 합에 관한 론의 를 고찰하자. 고전적명세작성단계 의 
한가지 과제 는 목적하는 제 품의 자료와 작용들을 결 정하는것 이 다. 그러 나 특정한 모둘에 
로 각이한 작용들의 병 합은 설 계단계 까지 머 루어 야 한다. 왜 냐하면 11. 16에 서 제 시한바와 
같이 먼저 제 품은 전체 로서 모둘로 어 떻게 갈라 넣 겠는가를 결정하여 야 하기때 문이 다. 
그러 나 객체지향파라다임 에서 이 과제는 분석단계 에 속한다. 즉 객체지향분석단계 에서 
모둘(콜라스)들과 그 속성 들을 결정한다. 그리 고 그 결과를 클라스선도로 묘사한다 (12.4). 
결국 명백히 클라스에로 방법들을 병 합하기 에 앞서 객체지향설계단계 까지 기다려야 할 
아무런 리 유도 없 다. 

그러 나 객체지향분석 이 반복과정이 라는것을 명 심하는것 이 중요하다. 각이한 모 
형들을 개선해 나가는 과정에 흔히 클라스모형의 많은 몫이 재조직되여야 한다. 클 
라스와 그 속성 들을 재 조직하는데는 시 간이 많이 소비 된 다. 그다음 방법 들을 재 병 합 
하는것 은 불필요한 추가적 인 재작업 을 산생 시킨다. 

00 A 과정의 매 걸음에서 반복기간에 재조직되여야 할 정보를 최소화하는것이 좋은 
착상으로 된다. 그러 므로 클라스에 로 방법 들의 병 합은 객체지향분석단계 에서 좀더 나갔으 
면 하는 생 각이 있 어 도 설 계단계 까지 기다려야 한다. 
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요 약 


객체지향분석 이 소개되였다 (12.1). 객체지향분석단계의 세개의 단계 즉 유스- 
케스모형 화 (12.3), 콜라스모형 화(12.4)， 동 적 모형 화 (12.5) 가 서술되였다. 이 단계들 은 
승강기문제 (12.2 에서 재서술된)에 적 용된다. 객체지향분석단계 에서의 시험은 12.6 의 주제 
이 다. 객 체지 향분석 을 위 한 CASE 도구들이 12.7 에 서 서 술된다. 이 장은 항공음식 전문회 사 
실례연구 (12.8) 와 객체지향분석단계의 난관 (12.9) 으로 결속된다. 

보 충 

객체지향분석의 서 로 다른 판본들을 서술한 초기의 문헌들로는 [Coad and Yourdon , 
1991 a ; Rumbaugh et al ., 1991; Shlaer and Mellor , 1992; and Booch , 1994] 이 있 다. 이 장에 
서 언급한바와 같이 이러한 기법들은 기본적으로 류사하다. 

이러한 류형의 객체지향분석기법들 외에도 Fusion [Coleman et al ., 1994] 은 OMT 
[Rumbaugh et al ., 1991] 과 Objectory [ Jacobson , Christerson , Jonsson , and Overgaard , 1992] 
를 비 롯한 1 세 대기 법들을 결합한 2세대 OOA 기 법 이 다. 통합된 쏘프트웨 어개 발공정은 재롭 
숀，브츠, 름바우의 연구를 통합한것이다 [ Jacobson , Booch and Rumbaugh , 1999]. Catalysis 
는 또 하나의 중요한 객체지향방법 론이 다 [ D’Souza and Mills , 1999]. 

ROOM 은 실시 간쏘프트웨 어 를 위 한 객 체 지 향방법 론이 다 [ Selic ， Gullekson , and Ward , 

1995] . 실 시 간객 체 지 향기 술들에 대 한 그이 상의 정 보는 문헌 [ Awad ， Kuusela , and Ziegler , 

1996] 에서 찾아 볼수 있다. 

문헌 [Lee and Tepfenhart , 1997, and Fowler , 1997 b ] 에서 UML 1.0 판에 대 한 소개 를 하 
였다. 문헌 [ Booch , Rumbaugh , and Jacobson , 1999, and Rumbaugh , Jacobson , and Booch , 
1999] 에 서 UML 과 관련 한 아주 상세 한 내 용들을 서 술하였 다. Communications of the ACM 
1999 년 10 월 호에 는 UML 의 리용과 관련 한 아주 다양한 론문들이 있 다. 

이 장에서 리용한 후보클라스를 추출하는 명사추출기 법은 문헌 [ Juristo , Moreno , and 
Lopez , 2000]. CRC 카드는 문헌 [Beck and Cunningham , 1989] 에 서 처 음으로 제 기하였 다. 
문헌 [ Wirfs - Brock , Wilkerson , and Wiener , 199 이은 CRC 카드에 대 한 아주 중요한 정 보원천 
으로 되고 있다. 

Communications of the ACM 1992 년 9 월호에는 객체지향분석에 관한 많은 기사들이 들 
어 있다. 객체지향분석기법에 대한 일부 비교에 대하여서는 문헌 [de Champeaux and Faure , 
1992; Monarchi and Puhr , 1992; and Embley , Jackson , and Woodfield , 1995] 을 비롯하여 여 
러가지 문헌들에 발표되 였 다. 객체지향과 구조화분석 기 법사이의 비 교에 대 하여서 는 문헌 
[Fichman and Kemerer , 1992] 에 서 고찰하였 다. 

객체지향프로젝 트에서 반복의 관리는 문헌 [ Williams , 1996] 에서 서술하였다. 상태도 
(10.6.1) 는 객체지향파라다임에로 확장되였다. 이에 대하여서는 문헌 [ Coleman , Hayes , and 
Bear , 1992] 와 [Harel and Gery , 199 기에서 서 술하고 있다. 객체 지향파라다임 에 서 설계 명세 
서 의 재 리용은 문헌 [ Bellinzona , Fugini , and Pemici , 1995] 에 서 서 술하고 있 다. 문헌 
[ Kazman , Abowd , Bass , and Clements , 1996] 에서는 객체지 향분석 에 쓰이는 대 본의 리 용을 
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제기하고 있다. 


문 제 

12.1. 그림 12-9 에 보여 준 다른 클라스에 대한 상태도를 개발함으로써 승강기문제 
실 례연구를 완성 하시 오. 

12.2. 객체지향분석 을 리용하여 문제 8.7 의 자동화된 서 고순환체 계 를 명 시하시 오. 

12.3. 11. 6 의 유한상태 기계형 식화를 왜 객체지향분석 에서 변화시키지 않고 리용할수 
없는가? 

12.4. 객 체지향분석 을 리용하여 문제 8.9 의 ATM 을 조종하기 위한 쏘프트웨어 를 명 시 
하시 오. 여기서 카드읽 기장치，인쇄 기, 현금분배 기와 같은 하드웨 어요소들의 세부들은 고 
찰할 필요가 없다. 그대신 단순히 ATM 이 이 요소들에 지령을 보낼 때 그 지령들이 정확 
하게 실행된다는것을 가정하시오. 

12.5. 제 품에 불리한 영 향을 주지 않으면서 클라스들이 도입 될수 있는 객체 지향분석 
과정에서의 최신측면은 무엇인가? 

12.6. 클라스들이 의미있게 도입될수 있는 객체지향파라다임에서의 최초의 측면은 
무엇인가? 

12.7. 이 장에서 서술한 상태도와 다른 형식을 리용하여 동적모형을 표현할수 있는가 
를 설명하시오. 

12.8. 왜 클라스들의 방법 이 아니 라 속성들이 객체지향분석 기 간에 결정된다고 생 각하 
는가? 

12.9. (과정 안상 목표)객 체 지 향분석 을 리용하여 부록 1 에 서 술된 브로드렌 즈지 역 아동 
병 원제 품을 명 시하시 오. 

12.10. (실례연구)클라스 Meal 을 항공음식전문회사 실례연구 (12.8) 의 객체지 향분석 에 
추가하시 오. 

12.11. (실례연구) 객체 지향분석 을 동적모형화로 시 작하면 무슨 현상이 발생 하는가를 
결 정하시 오. 그림 12-6 의 상태 도로 시 작하여 항공음식 전문회 사 실 례연구에 대 하여 객 체 
지 향분석 과정 을 완성 하시 오. 

12.12. (실례연구) 11.4 의 구조화체 계 분석 을 12.8 의 객체 지향분석 과 비 교하고 대 조하 
시오. 

12.13. (쏘프 트웨 어 공학독본) 교원은 문헌 [Harel and Gery , 199기의 복제 본을 배 포할 
것이다. 상태도표를 OOA 에서 상태도를 대신하여 응용할수 있는가? 
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제 1 3장. 설 계 단 계 


지난 35년간 수백가지 설계기법들이 제시되였다. 일부는 현존기법들에 대한 변종이 
며 일부는 이전에 제안된 기법들과 근본적으로 다르다. 한두가지 설계기법들은 수만명의 
쏘프트웨 어공학자들에 게 리용되 였 으며 대 부분은 그 제 안자들만이 리용하였 다. 일부 설 계 
전략들 특히 대학들에서 개발한것들은 확고한 리론적기초를 가지고 있다. 대학들에서 개 
발한것들을 포함하여 일부는 보다 실용주의적 이다. 즉 그것들은 그 제 안자들이 그 방법 
들이 실천에서 잘 동작한다는것을 알았기때문에 제시되였다. 대다수 설계기법들은 수동 
적이지만 자동화가 점차 설계의 중요한 측면으로 되고 있는데 다만 문서의 관리를 지 
원하기 위한 경 우만 놓고 보아도 그렇 다. 

설계기법들이 이처럼 많음에도 불구하고 거기에는 일정한 기초적인 형식이 있다. 이 
책의 주요화제는 어떤 제품의 두가지 본질적인 측면은 그것의 작용과 이 작용이 조작하 
는 자료이라는것 이 다. 그러 므로 어 떤 제 품을 설계하는 두가지 기 본적 인 방법 은 작용지향 
설계 와 자료지 향설계 이 다. 작용지 향설계 c / e 야 g «) 에 서 중요한것 은 작용들이 
다. 한가지 실례는 자료흐름분석인데 여기서 목적은 고도의 응집도를 가진 모둘들을 설 
계하는것 이 다 (7.2). 자료지향설계(쇼 to - on 如 tec / 에 서 는 자료가 우선적 으로 고찰된다. 

실례로 잭슨 ( Jackson ) 의 기법에서 (13.5) 자료의 구조가 먼저 정의되고 그다음 그 자료구조 
에 따라 절차가 설계된다. 

작용지향설계 기 법의 약점은 그것 이 작용들에 집중하고 자료의 중요성은 2차로 한다 
는것 이 다. 자료지향설 계 기 술은 이 와 류사하게 자료를 우선 강조하며 작용을 덜 중요시 한 
다. 해결대 책은 객체지향기술을 리용하는것 인데 이것은 작용과 자료에 갈은 비 중을 두고 
있다. 이 장에서 작용지향 및 자료지향설계를 먼 저 서술하고 그다음 객체지향설계 가 서 
술된다. 하나의 객체 가 작용과 자료를 모두 병 합하고 있는것과 마찬가지 로 객체지향설계 
는 작용지향설계 와 자료지향설계 의 특성 을 결합시 킨다. 그러 므로 객 체지향설계 를 원만히 
리해 하기 위 하여서 는 작용지향설계 및 자료지향설계 에 대 한 기 본적 인 리해를 가지 는것 이 
필요하다. 

특정한 설계 기 법 들을 시 험 하기 에 앞서 설계 단계 에 관하여 일부 일 반적 인 주의 를 줄 
필요가 있다. 


13.1. 설계와 추상화 

쏘 프트웨 어 설 계 단계 는 세 개의 활동 즉 구성 방식 설 계，상세 설계，설계 시 험 으로 이루어 
진다. 설계공정에 대한 연구는 명세서 즉 그 제품이 무엇을 하게 되는가에 대한 서술이다. 
출력은 설계공정의 설계 문서 즉 제품이 이것을 어떻게 달성 하여 야 하는가에 대한 서술이 다. 

구성방식설계(고 cMertwra / cfc 初 j )( 또는 일반설계，론리설계，고준위설계로 알려 져 있 
다.)기간에 제품의 모둘분해가 전개된다. 즉 명세서가 주의 깊게 분석되고 희망하는 기능을 
가진 모둘구조가 생성된다. 이 활동의 결과는 모둘들의 목록과 모둘들이 어떻게 결합되게 
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되는가에 대한 서술이다. 추상화의 관점으로부터 구성방식설계기간에 일정한 모둘들의 존 
재가 가정되고 그다음 이 모둘들에 의하여 설계가 전개된다. 객체지향파라다임이 리용될 
때 1.6 에서 설명한바와 같 이 구성 방식설계 활동의 부분은 객체지향분석단계 에서 수행된다 
(12 장). 이것은 00 A 에서의 첫 단계 가 클라스들을 결정하는것 이 기때 문이 다. 하나의 클라스 
는 한가지 류형 의 모둘이 기 때 문에 모둘분해 의 일 부 과정 은 분석단계 에 서 수행 되 였 다. 

다음활동은 상세설계(쇼 cfe 야 g «) 인데 이것은 또한 모둘설계, 물리적설계, 저준위 
설계 로 알려 져 있다. 이 단계 에서 매 모둘이 세부적 으로 설계된다. 실례 로 특정한 알고 
리듬들이 선택되고 자료구조들이 선택된다. 또한 추상화의 관점으로부터 이 활동기간에 
모둘들이 서 로 련결되 여 하나의 완전한 제 품을 형 성하게 된다는 사실 이 무시된다. 

이 두 단계 의 과정 은 계 7장에 서 서 술한바와 같이 전형 적 인 추상화이다. 우선 최 상위 
준위(전체 제 품)가 아직 존재하지 않는 모둘들에 의하여 설계 된다. 그다음 매 모둘들이 
그것이 완전한 제품의 하나의 구성요소로 된다는것을 고려함이 없이 차례로 설계된다. 

설계단계가 세개의 활동을 가지며 그 세번째 활동이 시험이라는것은 이미 서술하였 
다. 시험이 전체적인 쏘프트웨어개발 및 유지정비과정의 완전한 부분으로 되는것과 마찬 
가지 로 그것 이 설계의 완전한 부분이 라는것 을 강조하기 위하여 단어 단계 Cstoge ) 또는 걸 
음(있⑦)이 아니라 활동여 cftV 均;)이 리용되였다. 시험은 구성방식설계와 상세설계가 완성된 
다음에만 수행 되 는 활동이 아니 다. 

여 러 가지 각이한 설계 기 법 들을 이 제 고찰한다. 먼저 작용지향기법 을 설명 하고 그다 
음 자료지향기법 그리 고 마지 막으로 객체지향기법들을 설명한다. 

13.2. 작용지향설계 

7.2 과 7.3 에서는 어떤 제품을 고도의 응집도와 낮은 결합도를 가진 모둘로 분해 하기 
위한 한가지 리론적실례를 제시하였다. 이제 이러한 설계목적을 달성하기 위한 두가지 
실천적기법들 즉 자료흐름분석 (13.3) 과 트랜잭션분석 (13.4) 을 서술한다. 리론적으로 자료 
흐름분석은 명세서들이 자료흐름도로 표현될 때마다 적용될수 있다. 그리고 (적어도 리 
론적 으로) 매 제 품은 DFD 로 표현될수 있기 때 문에 자료흐름분석 은 광범히 응용될수 있 다. 
그러 나 실천적 으로 많은 경 우 보다 적 당한 설계 기 법 들이 존재하는데 특히 자료의 흐름이 
다른 고찰보다 2차적 인 제 품들을 설 계하는 경 우에 그러하다. 

다른 설계기법블이 필요한 실례들은 규칙에 기초한 체계(전문가체계), 자료기지, 트랜 
잭션처리 제품들이다 (13.4 에서 서술된 트랜잭션분석은 트랜잭션처리제 품들을 모둘로 분해 
하기 위 한 좋은 방법 이 다.). 


13.3. 자료흐■분석 

자료흐름분석 (Ztoa Flow Analysis ; DFA ) 은 고도의 응집도를 가진 모둘들을 얻기 위 한 
설계기법이다. DFA 는 대부분의 명세작성기법과 함께 리용될수 있다. 이 절에서 DFA 는 
구조화체계분석 (11.3) 과 함께 제시된다. 이 기법에 대한 입력은 자료흐름도이다. 중요한 
점 은 일 단 DFD 가 완성 되 면 쏘프트웨 어 설 계 자는 그 제 품에 대 한 입 력 과 그 제 품의 출력 



을 고려하여 정확하고 완전한 정보를 가지게 된다는것 이다. 



입력모둘 J 전송모둘 j 출력모듈 

입력의 최고추상점 출력의 최고추상점 


그림 13-2. 입력과 출력의 최고추상점들 

그림 13-1 의 DFD 에 의하여 표현된 제 품에 서 의 자료흐름을 고찰하자. 이 제 품은 
어쨌든 입력을 출력으로 변환한다. DFD 의 어떤 점에서 입력은 입력이기를 그만 두고 
어떤 종류의 내부자료로 된다. 그러면 어떤 이후점에서 이 내부자료들은 출력의 자격을 
가지게 된다. 이것은 그림 13-2 에서 보다 자세히 보여 준다. 그 입력 이 입력으로 될 
자격을 잃고 단순히 제품이 조작하는 내부자료로 되는 점을 입력의 최고추상점 ( po 治/ of 
hightest abstraction of 治/)때이 라고 부론다. 이와 류사하게 출력의 최 고추상점 ( po 初/ of 
hightest abstraction of output ) 은 출력 이 어 떤 종류의 내 부자료로서 가 아니 라 출력 으로서 
식별될수 있는 자료흐름에서의 첫 점이다. 

입 력과 출력의 최 고추상점 을 리용하여 제품을 세개의 모둘 즉 입 력모둘，변환모둘, 
출력모둘로 분해한다. 이 제 매 모둘이 차례 로 취 해 지 고 그것 의 최 고추상점 이 찾아 지 
며 모둘은 다시 분해 된 다. 이 절 차는 매 모둘이 단일한 작용을 수행할 때 까지 계 단식으 
로 계속된다. 즉 설계는 고도의 응집도를 가진 모둘들로 이루어 진다. 결국 그토록 많은 
다른 쏘프트웨 어공학기 법 들의 기 초로 되 는 계 단식 세 련은 또한 자료흐름분석 의 기 초를 
이 룬 다. 

공정 하게 말하면 최 저 결합가능성 을 달성 하기 위하여 분해 에 약간한 변경 이 가해 져 
야 할수도 있 다. 자료흐름분석 은 고도의 응집 도를 달성 하기 위한 한가지 방법 이 다. 혼합 
식 구조화설 계 의 목적 은 고도의 응집 도뿐아니 라 낮은 결 합도를 달성하는것 이 다. 낮은 결 
합도를 달성하기 위하여서는 때때로 설계에서 약간한 변경을 가하는것이 필요하다. 실례 
로 DFA 는 결 합도를 고려 하고 있지 않기 때 문에 DFA 를 리용하여 구성된 설계 에서 무심 
결에 결합도조종이 일어 날수도 있다. 이와 같은 경우에 필요한것은 조종이 아니 라 자료 
가 통과되 도록 포함된 두개 의 모둘을 변경하는것 이 다. 
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13. 3. 1 . 자료흐■분석실례 


UNIX wc 편의프로그람과 류사하게 어 떤 파일 이 름을 입 력 으로 하고 그 파일안의 단 
어 수를 귀 환하는 제 품을 설 계하는 문제 를 고찰하자. 

그림 13-3 은 자료흐름도를 묘사하고 있다. 거기에는 5개의 모둘이 있다. 모둘 read 
file name 은 파일 의 이 름을 읽 으며 그다음 그것 은 모둘 validate file name 에 의 하여 확인 
된다. 확인된 이름은 모둘 count number of words 에 로 넘 겨 지며 이 모둘은 단어 개수를 
정 확히 계산한다. 총 단어 수는 모둘 format word count 로 넘 겨 지 고 최종적 으로 형 식 화된 
총 단어 수가 출력 을 위 하여 모둘 display word count 에 로 넘 겨 진 다. 



여기에 입력- ►_! L -- 여기서부터 를력 


입력의 최고추상점 출력의 최고추상점 


그림 13-3. 자료흐름도: 첫번째 세련 

자료흐름을 검 토할 때 초기입 력은 파일 이름야 /e mwze ) 이 다. 이것 이 확인된 파일이름 
(validated file name) 으로 될 때 그것 은 여 전히 하나의 파일 이 름이 며 그러 므로 입 력 자료로 
서의 자격 을 잃지 않는다. 그러 나 모둘 count number of words 를 고찰하면 그것의 입 력 
은 validated file name 이며 출력 은 word count 이 다. 이 모둘의 출력 은 자격 에서 제품에 대 
한 입력과 완전히 다르다. 입력의 최고추상점은 그림 13-3 에 지적된것과 같다. 류사하게 
모둘 count number of words 로부터 의 출력 에 어 떤 종류의 형 식 화를 진행 한다고 하여 도 
그것 은 본질 상 모둘 count number of words 로부터 나올 때 의 출력 이 다. 그러 므로 출력 의 
최고추상점은 그림 13-3 에 보여 준것과 같다. 

이 두개 의 최 고추상점 을 리용하여 제 품을 분해한 결 과를 그림 13-4 의 구조도표에 보 
여 주었다. 그림 13-4 는 또한 그림 13-3 의 자료흐름도가 어느 정도 단순하다는것을 보여 
준다. DFD 는 만일 사용자가 명시한 파일이 존재하지 않으면 무슨 현상이 발생 하는가에 
대응하는 론리적 흐름을 보여 주지 않는다. 모둘 read and validate file name 은 하나의 상 
태 기 발 ( sto / 새 /7 ag ) 을 모둘 perform word count 에 귀 환하여 야 한다. 만일 이 름이 타당하지 
않으면 그것 은 모둘 perform word count 에 의 하여 무시 되 며 어 떤 종류의 오유통보가 인쇄 
된다. 그러 나 만일 이름이 타당하면 그것은 모둘 count number of words 에 넘 겨 진다. 

일 반적 으로 조건적자료흐름이 존재하는 곳마다 대 응하는 조종흐름이 요구된 다. 

그림 13-4에서 두개의 모둘 read and validate file name 파 format and display word 
count 는 통신적 인 응집도를 가진다 (7.2.5) 이 모둘들은 더 분해되여야 한다. 최종결과를 
그림 13-5 에 보여 주었다. 8개의 모둘전부가 자료결합을 가지든가 또는 그것들사이의 결 



















모듈이름 

validate file name 


모듈형 

함수 


귀환값형 

Boolean 


입 력 변수 

file name : string 


출력 변수 

없음 


오유통보문 

없음 


호출된 파일 

없음 


변경된 파일 

없음 


호출된 모듈 

없음 



이 모듈은 조작체계사 

1- 호출하여 파일 file name 이 존재 하는가 

해설 

를 결정한다 . 모듈은 
false 를 귀환한다 . 

파일 이 존재하면 true, 그렇 지 않으면 


count number of words 
함수 
Integer 

validated file name : string 
없음 ' 

없음 

없음 

없음 

없음 

이 모둘은 validated file name 이 여 러 행 들로 분할된 본문 
파일 인 가를 결 정한다 . 그렇 다면 모듈은 본문파일 에 있 는 단 
어의 수를 귀환하고 그렇지 않으면 一 1 을 귀환한다 . _ 


모듈이름 

product output 

모듈형 

함수 

귀환값형 

void 

입력 변수 

word count : integer 

출력변수 

없음 

오유통보문 

없음 

호출된 파일 

없음 

변경된 파일 

없음 

format word count 
변수 : word count : string 

호출된 모듈 

formatted word count : string 
display word count 
변수 : formatted word count : string 


이 모듈은 호출모듈에 의하여 넘겨 진 옹근수 word count 를 
가지 고 있으며 설계명세 에 따라 형 식화된 옹근수를 얻 을수 
있도록 format word count 를 호출한다 . 그다음 display word 
count 를 호출하여 인쇄된 행들을 얻어 낸다 . _ 


모듈이름 
모듈형 
귀환값형 
입 력 변수 
출력 변수 
오유통보문 
호출된 파일 
변경된 파일 
호출된 모듈 

해설 
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그림 13-6. 실례의 네개 모듈에 대한 상세설계 





void perform word count() 

{ 

String validated file name; 
int word count; 

if (get input (validated file name) is false) 
print “error 1 : file does not exit” ; 
else 

word count 를 count number of words (validated file name ) 와 같게 설정 한다 ; 
if (word count is equal to 一 1) 
print “error 2 : file is not a text file” 
else 

produce output (word count); 

} 

} 

Boolean get input (String validated file name) 

{ 

String file name; 

file name = read file name (); 

if (validate file name (file name) is true)( 

{ 

validated file name 을 file name 으로 설정 한다 ; 

return false; 

else 

return false; 

} 

void display word count (String formatted word count) 

{ 

print formatted word count , left justified .， 

} 

String format word count ( int word count); 

{ 

return “File contains” word count “words” ); 

} 

그림 13-7. 실례의 네가지 방법에 대한 상세설계의 PDL ( 의사코드)표현 

여기까지에서 구성방식설계가 완성되였으며 그 다음단계는 상세설계이다. 여기서 자 
료구조들이 선택되고 알고리듬들이 선택된다. 그다음 매 모듈에 대한 상세설계가 실현을 
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위하여 프로그람작성자에게 넘겨 진다. 사실상 쏘프트웨어제품생산의 다른 매 단계들과 
마찬가지로 시간제약은 쏘프트웨어실현이 모든 모둘들을 코드화할 책임이 있는 개별적프 
로그람작성자에 의해서가 아니라 하나의 개발림에 의하여 이루어 질것을 요구한다. 이러 
한 원인으로 하여 매 모둘들의 상세설계는 다른 임의의 모둘을 참고하지 않고 리용될수 
있도록 제시되 여 야 한다. 8개의 모둘중에서 4개에 대 한 상세설계 가 그림 13-6 에 제시되 
였다. 다른 4개 의 모둘들은 다른 형 식 으로서 제 시된다. 

그림 13-6 의 설계 는 프로그람작성언어 와는 무관계하다. 그러 나 만일 관리 자측이 상 
세 설계 를 시 작하기전에 실천언어 를 결정 하기 로 한다면 상세 설계 를 표현하기 위하여 프로 
그람서 술언어 (Program Description Language ; PDL ) 를 리 용하는것 이 한가지 흥미 있는 대 
안으로 된다(의사코드는 PDL 에 대한 이전의 이름이다.). PDL 長 본질상 선택 
된 실현언어의 조종명령문 ( contra / statement ) 느로 련결된 설명문들로 이루어 진다. 그림 
13-7 은 C ++ 또는 Java 양상의 PDL 로 작성 한 이 제 품의 나머 지 4개 모둘에 대 한 상세 설 
계를 보여 주고 있다. PDL 은 그것이 일반적으로 명백하고 간결하며 따라서 실현단계는 
보통 설명 문들을 련관된 프로그람작성언어 로 순수 번역하여 이루어 진다는 우월성 을 가 
지 고 있 다. 부족점 은 때때 로 설계 자들이 지 나친 세 부에 들어 가서 PDL 상세설계 가 아니 
라 모둘의 완전 한 코드실 현을 초래하는 경 향이 존재 한다는것 이 다. 

상세설계 는 완전히 문서 화되 고 성 과적 으로 시 험된후에 코드작성 을 위하여 실현림 에 
넘 겨 진다. 그다음 제품은 쏘프트웨 어개 발공정의 나머지 단계들을 거 치게 된다. 

1 3. 3. 2. 확 장 

독자들은 이 실례가 약간 인공적이라는것을 느낄수 있는데 실례에서 자료흐름도(그 
림 13-3) 는 다만 하나의 입 력흐름과 하나의 출력 흐름을 가지 고 있 다. 보다 복잡한 상황 
에서 무슨 현상이 발생 하는가를 보기 위하여 그림 13-8 을 고찰하자. 여 기 에는 4개의 입 
력흐름과 5개 의 출력흐름이 있는데 상황은 현실 에 보다 가깝게 대 응하고 있 다. 



다입 출력흐름이 존재할 때 진행해 나가는 방법은 매 입 력흐름에 대 한 입 력의 최 고추 


418 












자화카드를 구멍에 넣고 통과암호를 입력하면 당좌예금, 시좌예금 
하는것，구좌에서의 자금대출, 구좌에서 잔고결정과 같은 작용들필 
i 의 제품을 그림 13-9 에 보여 주었다. 이와 같은 제품을 설계하기 
법은 그것을 두 부분 즉 분석기와 처리기로 가르는것이다. 분석기나 
균 하고 이 정보를 처 리기 에 보내며 처 리기는 트랜잭션을 수행한다. 



의 한가지 불충분한 설계를 그림 13-10 에 보여 주는데 그것 
L 개 의 모둘 edit any 仕 ansaction 과 update any flie 을 가지 고 있 
련집모둘들과 5개의 매우 류사한 갱신모둘들을 작성하는것로 
한 해 결 방안은 쏘프트웨어 의 재 리용이 다 (8.1). 즉 하나의 기 - 
성되고 문서화되고 시험되며 그다음 그것이 5번 실례생성독 
우지만 그 차이는 이 방법의 유용성을 충분히 담보할만큼 ^ 
1본갱 신모둘이 5번 실례생성되 여 5개의 각이한 갱 신모둘들홀 
=• 있다. 최종설계는 고도의 응집도와 낮은 결합도를 가지게 






트랜잭션분석방법을 아래의 란에 종합한다. 


트랜책션분석을 진행하는 방법 

• 구조는 두개의 요소 즉 분석기와 처리기로 구성된다 . 

• 매개의 련관된 작용들의 모임에 대하여 하나의 기본모듈을 설계하고 
그것을 필요한 회수만큼 실례생성한다 . 


13.5. 자료지향설계 

자료지향설계의 리면에 있는 기본원리는 조작하려는 자료의 구조에 따라 제품을 설계 
하는것이다. 다시 말하여 우선 자료의 구조가 결정되고 그다음 매 절차들이 조작하려는 자 
료와 같은 구조로 주어 진다. 이와 갈은 류형의 자료지향기법들은 많이 존재하고 있다. 가 
장 널리 알려 진것들로서는 미카엘 잭슨 (Michael Jackson )[ Jackson , 1975], 와니 어 ( Wamier ) 
[ Wamier , 1976], 오르 ( Orr )[ Orr , 1981] 의 기법들인데 이 세가지 기법들은 많은 류사성을 가 
지고 있다. 

자료지향설계 는 작용지향설게 처 럼 그렇 게 보편적 이지 는 못하며 객체지향파라다임의 
출현으로 하여 크게 류행 되 지 않고 있 다. 지 면상의 리유로 하여 이 책 에서 는 자료지향설 
계를 더 이상 론의 하지 않는데 흥미 있는 _복자들은 우에 제시된 참고문헌들을 보시 오. 

13.6. 객체지향설계 

객 체 지 향설 계 { object-oriented design ; 00 D ) 의 목적 은 객 체 즉 객 체 지 향분석 단계 에 서 
추출된 클라스 및 부분클라스들의 실례 에 의하여 제품을 설계하는것 이 다. C , COBOL , 
FORTRAN , Pascal 과 같은 고전적 인 언어들은 이 와 같은 객체들을 지 원하지 않는다. 이것 
은 OOD 가 Smallta 1 k [ G oldberg and Robson , 1989], C ++[ S 仕 ous t rup , 1991], E iffel [ Meyer , 
1992 bI ， Ada 95[ ISO/lEC 8652, 1995], Java[Flanagan and Loukides , 1997] 와 같은 객체지향언 
어 들이 사용자들에 게 접 근가능하다는것 을 의 미하는것 갈을수도 있 다. 

실정은 그렇지 않다. 비록 OOD 가 고전적 인 언어들로 지원되지는 않는다 하여도 OOD 
의 많은 부분들은 리용될 수 있 다. 7.7 에 서 설 명한것 처 럼 클라스는 계 승을 가지 는 추상자 
료류형이며 객체는 클라스의 실례이다. 계승을 지원하지 않는 어떤 실현언어를 리용할 
때의 해결방안은 그 프로젝트에서 리용된 프로그람작성언어로 달성될수 있는 OOD 의 측 
면들을 리 용하는것 즉 추상자료류형 설 계 ( afcfrac / data type design ) 를 리용하는것 이 다. 추 
상자료류형은 사실 형 ( type ) 명령을 지원하는 임의의 언어로 실현될수 있다. COBOL 과 같 
은 고전적언어 에 서 조차도 자료교갑화를 실현하는것 은 여 전히 가능할수 있 다. 그림 7-29 
는 모둘로서 시 작하고 객체 로서 끝나는 설계개 념의 계층구조를 보여 주고 있다. 완전한 
OOD 가 가능하지 않은 경 우들에 개 발자들은 자기 들의 설계 가 설계언어 가 지 원하는 그림 
7-29 의 계층구조에서 최상의 가능한 개념을 리용한다는것을 확증하기 위하여 노력하여야 
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한다. 

00 D 는 다음의 네 단계로 이루어 진다. 

1. 매 대 본에 대 하여 호상작용도를 구성한다. 

2. 세 부클라스도를 작성한다. 

3 . 객 체 들의 의 뢰 자에 의하여 제 품을 설 계한다. 

4. 상세설계 를 진행한다. 


이 제 OOD 를 한가지 실 례 로서 례 증한다. 앞에 서 와 마찬가지 로 단순하게 하기 위하여 
한대 의 승강기 를 가진 승강기문제 가 제 시 된다. 같은 실례 를 리용함으로써 문제 그자체 의 
작은 세 부들에 대 하여 념 려하지 않고 각이한 방법 들을 비 교할수 있 다. 

13.7. 승강기문제: 객체지향설계 

1단계. 매 대본에 대한 호상작용도를 구성한다 UML 은 두가지 류형의 호상작용도 즉 
순차도와 협동도를 지원한다. 이 두개의 선도들은 동일한것들 즉 객체들과 그 객체들을 
통과하는 통보들을 보여 준다. 그러나 이 두 선도에서 중점은 서로 다르다. 순차도는 통 
보들의 명백한 시 간적 인 순서를 강조하고 있다. 그러므로 순차도는 사건발생의 순서 가 
중요한 정황에서 쓸모 있다. 협동도는 객체들사이의 관계를 강조하고 있으며 쏘프트웨 어 
제 품의 구조를 리해 하기 위한 하나의 강력한 수단으로 된 다. 

그림 12-10 의 대본(여기서는 그림 13-11 로 재현되고 있다.)을 고찰하자. 그림 13-12 
의 대응하는 순차도에서 사용자들과 객체들은 수직선들로 표현된다. UML 에서 어떤 콜라 
스의 실례(하나의 객체)는 밑선을 친 소문자로 된 클라스이름으로 표현된다. 

시간은 상단에서부터 하단으로 향한다. 그림 13-11 의 대본에서 첫번째 사건은 사용 
자 A 가 상승층단추를 누른다는것 이 다. 이것은 1. press floor button 으로 표식 한 User A 로 
부터 floor button 에로 향하는 수평선으로 표현된다. 다음으로 층단추는 승강기조종기에 
층단추가 눌러 졌다는것(대본의 사건 2) 을 통보한다. 이것은 floor button 로부터 elevator 
controller 로 향하는 수평선으로 표현된다. 승강기조종기는 그다음 련관된 층 단추에 통보 
를 보내 여 그 단추를 견다(대 본의 사건 3). 이것은 3. turn button on 으로 표식 한 elevator 
controller 로부터 floor button 에로 향하는 수평선으로 표현된다. 대본에서 4번째 사건은 
승강기조종기 가 일 련의 통보들을 승강기 에 보낸 결과로 승강기 가 3층에 도착한다는것 이 
다. 이것은 한층 우로 올라 가기 위 하여 elevator controller 가 elevator 에 보내는 통보를 
반복하는것으로서 모형화된다. 이 반복은 4. *move up one floor 로 지적된다. 순차도의 나 
머지 부분은 류사하다. 

그림 13-12 는 그림 13-11 의 대본안에 있는 작용자들 즉 대본의 사건들에서 능동적인 
사용자들과 객 체 들을 먼 저 렬 거 하는것 으로서 구성 되 였 다. 작용자들은 User A (사건 1과 8), 
floor button (사건 1, 2, 3, 5), elevator controller (사건 2 부터 7 까지와 사건 9 부터 7 까지)， 
elevator (사건 4, 12, 16), elevator doors (사건 2, 10, 14, 16), elevator (사건 9, 10, 13) 들이다. 
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色 서술은 간단하게 하기 위 하여 생 략하였다.). 



7 1단추를 누르며 (사건 8) 승강기단추는 승강: 
.리 고 승강기 조종기 는 통보를 승강기단추에 - 











여 조명 을 견다(사건 10). 그다음 설정 시 간초과가 발생하며(사건 11) 승강기 조종기 는 문 
에 통보를 보내여 문을 닫는다. 이것은 그림 13-12 의 첫번째 시간계수순환의 끝이 사건 
10과 사건 11사이에 있는 elevator controller 를 표현하는 2중수직선과 마주치게 되는 리 
유이다. 같은 대 본에 대 한 협동도를 그림 13-13 에 보여 준다. 



User A 


그림 13-13. 그림 13-11 의 대본을 위한 협동도 

순차도와는 달리 협동도는 elevator controller 가 노는 중심적 인 역할을 명확히 보여 
준다. 사실 대 본에서 두개 를 제외 한 모든 통보들은 elevator controller 에 로 또는 그로부터 
보내 진다. 비록 두 선도가 모두 정확하게 같은 정보를 포함하고 있다고 하여도 그림 
13-12 의 순차도의 시 간정 보는 그림 13-13 의 협동도에서 명백하지 않다. 경 험은 매 프로 
직 트에 서 설 계 림 이 두개 의 호상작용선도가운데 서 어 느것 이 더 적 당한가를 결정하여 야 한 
다는것 이 다. 많은 경 우에 두개 가 다 필 요할것 이 다. 사실 쏘프트웨어 가 만일 OOA 와 OOD 
를위한 CASE 도구를 리용하여 개발된다면 그 모두는 요구에 따라 어느 한 선도를 발생 
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할수 있다. 이것은 림이 즉흥적으로 적당한 호상작용선도를 선택할수 있게 한다. 

그림 D -13 의 협동도는 이 대본에 관하여 그림 13-12 의 협동도와 같은 방식으로 구 
성되였다. 즉 작용자들은 그림 13-11 의 대본으로부터 추출되고 그림 13-12 에 그려 졌다. 
그다음 매 사건들은 차례로 조사되여 이 선도에 포함되였다. 실례로 사건 3에서 승강기 
조종기 는 승강기단추에 조명 을 컬 것 을 지 시 한다. 그러 므로 elevator controller 로부터 floor 
button 에 로 선이 그어 지며 그 선과 평 행 으로 작은 화살표가 배 치되고 3. turn button on 
으로 주석 이 달아 진다. 다른 사건들도 이와 류사하게 삽입된다. 

그림 13-12 의 순차도와 그림 13-13 의 협동도를 구성하는 공정 에서의 유일한 차이 는 
순차도에서 사건들은 련관된 작용자들의 이름을 포함하고 있는 통으로 시작되는 2중수직 
선에 련결되는 수평선들로 표현되며 반면에 협동도에서는 사건들이 작용자들의 이름을 
포함하고 있는 통들을 련결하는 선들을 따라 배치된 주석 불은 화살표들로 표현된다는것 
이다. 

2단계. 세부클라스도를 구성한다 OOA 단계의 클라스도는 (12.5) 클라스들과 그 속성들 
은 묘사하고 있지만 그것들의 작용자는 복사하지 않고 있다. 방법들은 OOD 단계의 세부 
클라스도에 삽입된다. 

제 품의 모든 작용들을 결정하는것 은 매 대 본의 호상작용선도들을 조사함으로써 수행 
된다. 이것은 간단하다. 어려운것은 어느 작용들이 매개 콜라스와 관련되여야 하는가를 
확정하는 방법 을 결 정하는것 이 다. 

하나의 작용은 하나의 클라스들과 그 클라스의 하나의 객체에 통보를 보내는 하나의 
의뢰자에게 할당될수 있다(어떤 객체의 한 의뢰자는 그 객체에 통보를 보내는 하나의 프 
로그람단위 이 다.). 이 런 작용을 어 떻게 할당하는가를 결정 하기 위한 한가지 방도는 정 보 
은폐 에 기초하는것 이 다. 즉 어떤 클라스의 상태 변수들은 private (그 클라스의 한 객체내 
에서만 접근할수 있다.)든가 protected (그 클라스의 한 객체 또는 그 클라스의 한 부분클 
라스내에서만 호출할수 있다.)로 선언되여야 한다. 따라서 상태변수에 대하여 수행된 작 
용들은 그 들라스에 대하여 국부적이여야 한다. 

정보은페가 전혀 요구되지 않는다고 하여도 만일 어떤 특별한 작용이 어떤 객체에 
대 한 서 로 다른 여 러 의뢰 자에 의하여 호출된다면 그 객체의 매 개 의뢰 자들안에서 복사 
를 하는것이 아니라 그 객체의 하나의 방법으로써 실현된 그 작용의 단일한 복사를 하는 
것이 합리적이다. 작용을 어디에 배치하는가를 결정하는 세번째 방법은 책임구동설계방 
법 을 리 용하는것 이 다. 

7. 6에서 설명한바와 같이 객체지향파라다임의 한가지 중요한 측면은 책임구동설계 
원리이다. 만일 어떤 의뢰자가 하나의 객체에 어떤 통보를 보내면 그 객체는 의뢰자의 
요청을 수행할 책임을 지게 된다. 의뢰자는 그 요청이 어떻게 수행될것인가를 모르며 
또 알도록 허가되지 않는다. 일단 요청이 수행되면 조종은 의뢰자에게 넘겨 진다. 이 
시점에서 의뢰자가 알게 되는것은 요청이 수행되였다는것이며 이것이 어떻게 달성되였 
는가에 대한 표상은 전혀 없다. 

이러한 기준들을 이제 승강기 문제의 실례 연구에 적용한다. 세부클라스도 (그림 13- 
14) 는 작용(방법)들을 그림 12-9 의 클라스도에 추가하여 엄어 진다 ( Java 실현의 경우에 


426 



두개의 추가적 인 클라스들이 필요하다. Elevator Application 은 C++ 기본함수에 대응하며 
Elevator Utilities 는 C++ 클라스들의 밖에서 선언된 C++ 함수들에 대응하는 Java 루린을 
포함한다.). 

승강기조종기 에 대 한 CRC 카드의 두번째 반복을 고찰하자(그림 12-8). 책 임들은 두개 
의 그를으로 된다. 책 임 8. Start timer, 10. Check requests, 1. Update requests 는 책 임구동설 
계 에 기 초하여 승강기 조종기 에 할당되 였 다. 즉 이 과제 들은 승강기 조종기 그자체 에 의하 
여 수행된다. 

한편 나머지 8 개의 책임(사건 1 부터 7 까지와 사건 9) 들은 《통보를 다른 클라스에 
보내여 그에게 무엇을 하는가를 알려 주라.》는 형식을 취한다. 이것은 클라스에 련관된 
작용을 할당할 때 리용되여야 하는 원리는 또다시 책임구동설계로 되여야 한다는것을 암 
시하고 있다. 이밖에 안전성과 관련하여 정보은페의 원리는 8개의 경우에 모두 동등하게 
응용될수 있다. 



그림 13-14. 승강기문제의 세부클라스 X 


이상의 두가지 리유로 하여 방법 close doors 와 open doors 는 클라스 Elevator Controller 
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에 할당되 였다. 즉 Elevator Doors 의 한 의뢰 자(이 경 우에 클라스 Elevator Cotroller 의 하 

나의 실례)는 클라스 Elevator Doors 의 한 객체에 통보를 보내여 승강기의 문을 닫든가 
연다. 이 요청은 련관된 방법에 의해서만 수행된다. 이 두 방법들의 매개 측면은 클라스 
Elevator Doors 내에 교갑화된다. 더우기 정보은페는 실지로 독립적인 하나의 Elevator 
Doors 콜라스를 생성시키는데 이것은 상세설계와 실현을 독립적으로 거처서 후에 다른 제 
품에 서 재 리용될 수 있 다. 

완전히 동일한 두개 의 설계원 리 들이 방법 move down one floor 와 move up one 
floor 에 적용되였는데 이 방법들은 클라스 Elevator 에 할당되였다. 승강기를 멈추도록 
명백한 지 령을 줄 필요가 없다. 만일 클라스 Elevator 의 두 방법들이 호출되지 않으면 
승강기는 움직일수 없다. 이 두 방법들중의 하나를 호출하지 않고 승강기의 상태를 
변화시킬수 있는 다른 방법은 없다. 

마지막으로 방법 turn button off 와 turn button on 은 두 클라스 Elevator Button 과 
Floor Button 에 모두 할당되 였다. 그 리 유는 클라스 Elevator Doors 와 클라스 Elevator 에 

방법들이 할당된것과 마찬가지이다. 첫째로, 책임구동설계 원리는 단추들이 켜지든가 꺼지 
든가에 대 하여 완전히 조종할수 있을것 을 요구한다. 둘째 로，정 보은페원리 는 어 떤 단추의 
내부상태 가 은폐될것을 요구한다. 승강기단추를 켜든가 끄는 방법들은 콜라스 Elevator 
Button 에 국한되여야 하며 클라스 Elevator Button 에 대해서도 이와 류사하다. 다형성과 
동적 결 합을 리 용하기 위 하여 방법 tum button on 과 turn button o 伴는 7.8 에 서 설명 한 리 유 
로 하여 기초콜라스 Button 안에서 추상적(가상적)방법으로 선언된다. 실행시에 방법 tun 
button on 의 정확한 판본이 호출될 것 이 다. 

3단계. 객체들의 의뢰자들에 의하여 제품을 설계한다 객체 0에 하나의 통보를 보내 
는 하나의 객체 C 는 0의 하나의 의뢰자로 된다. 호상작용도들은 매 객체의 의뢰자들 
을 보여 주는 선도를 작성하는데 리용된다. 의뢰 자 C 로부터 0에로 보내질 하나의 통 
보는 C 로부터 0로 향하는 하나의 화살표로써 표현된다. 

그림 13-15( 승강기문제의 C ++ 실현을 위한것)와 그림 13-16(Java 실현을 위 한것)은 각이 
한 콜라스들에 대한 협동도들로부터 직접 구성된다. 실례로 그림 13-11 의 대본(그림 13-14) 
에 대한 협동도에서 클라스 Elevator Controller 의 한 객체는 클라스 Elevator Controller , 
Elevator Button , Elevator Doors 및 Elevator 의 객체들에 통보를 보낸다. 또한 클라스 
Elevator Button 과 Elevator Button 의 객체 들은 클라스 Elevator Controller 의 하나의 객체 
에 통보들을 보낸다. 

어 떤 다른 객체의 의뢰 자로 되지 않는 임의의 객체는 일반적 으로 주프로그람에 의하 
여 시 작될 필요가 있 다. 승강기 문제 의 C ++ 실현에 서 함수 main 은 객 체 elevator controller 
를 호출하여 야 한다. Java 제품은 객체 elevator application 을 호출함으로써 동작을 시 작한 
다. 이 러한 형식의 구조는 객체지향파라다임 이 리용될 때 자주 쓰인다. 즉 간단한 주프로 
그람이 모든것들을 출발시키고 그다음 객체 그자체들이 넘겨 받는 형식의 구조이다. 

이제 전반적인 구성방식설계가 명확해 졌다고 하면 매 객체들이 요구하는 방법들을 
모두 가지고 있는가를 검열하는것이 필요하다. 즉 객체에 보내는 매 가능한 통보들에 객 
체가 응답할수 있도록 매개의 객체들에 요구되는 모든 방법들이 할당되였다는것을 검증 
하는것 이 필요하다. 이제 elevator controller 가 main (또는 elevator application ) 이 호출할수 
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있는 어 떤 추가적방법 을 요구한다는것 은 명 백하다. 그러 므로 그림 13-14 는 수정 되 며 방 
법 elevator event loop 가 클라스 Elevator Controller 에 추가된다. 그러면 이 방법은 
main (또는 elevator application ) 에 의 하여 호출될 수 있 다. 




4 단계 . 상세설계를 진행한다 이제 상세설계가 모든 클라스들에 대하여 전개된다. 제5 
장에서 서술한 계단식세련과 갈은 임의의 적당한 기법들이 리용될수 있다. 방법 elevator 
event loop 의 상세설계를 그림 13-17 에 보여 주었다. 여기서는 PDL (의사코드)이 리용되였 
지만 표현(그림 13-6 에서와 같은)방법도 마찬가지로 효과적일수 있다. 

그림 13-17 은 그림 12-6 의 상태 로부터 구성 된다. 실례 로 표식기 호 [button pushed, 
button unlit] 는 그림 13-17 의 서두에서 두개의 함유 if 명령문으로써 실현된다. 그다음 
상태 Process Requests 의 두개의 작용들이 제시된다. else-if 조건문은 Elevator Event 
loop 의 다음표식 기 히 elevator moving in direction d, floor f is next] 에 대 응한다. 상세 
설계 의 나머 지부분들은 모두 단순하다. 
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void elevator event loop(void) 

{ 

while (TRUE) 

{ 

if (button has been pressed) 
if (button is not on) 

{ 

update requests; 
button:: turn button on; 

} 

else if (elevator is moving up) 

{ 

if (there is no request to stop at floor f) 
elevator:: move one floor up; 

else 

{ 

stop elevator by not sending a message to move; 

elevator doors:: open doors; 
start timer; 

if (elevator button is on) 

elevator button:: turn button off; 
update requests; 

} 

} 

else if ( elevator is moving down) 

[ similar to up case ] 

else if ( elevator is stopped and request is pending) 

{ 

elevator doors:: close doors; 
if (floor button is on) 

floor button:: turn button off; 
determine direction of next request; 
elevator: : move one floor up/down; 

} 

else if ( elevator is at rest and not (request is pending)) 
elevator doors:: close doors; 
else 

there are no requests, elevator is stopped with elevator doors closed, so do nothing; 

} 

} 

그림 13-17. 방법 elevator event loop 의 상세설계 
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객체지향설계의 단계들을 아래의 란에 종합하였다. 


객체지향설계를 진행하는 방법 

- 매 대본에 대하여 호상작용도들을 구성 한다 . 

• 세부들라스도를 작성한다 . 

• 객체들의 의뢰자들에 의하여 제품을 설계한다 . 

• 상세설계를 진행한다 . 


1 3. 8. 상세설계를 위한 형식적기법 

상세설계를 위한 한가지 기 법은 이미 계 시되 였다. 5.1 에서 계 단식세 련방법 이 서 술되 
였다. 계 단식세 련방법 은 그다음 흐름도표를 리용하여 상세설계 에 적 용되 였 다. 계 단식세 련 
방법 이외 에 형 식적기 법들이 상세설계의 개선에 리용될수 있다. 제6장은 완전한 제품을 
실현하고 그다음 그것 이 정 확하다는것을 증명하는것은 비생산적일수 있다는것을 제기하 
고 있다. 그러나 증명과 상세설계를 병행으로 진행하는것과 코드를 주의 깊게 시험하는 
것 은 상당히 차이 나는 문제 이 다. 상세설계 단계 에서 형 식적기 법 들은 다음 세 가지 방법으 
로 도움을 줄수 있다. 

1. 정확성증명에서의 최신기법은 비록 그 기법이 일반적으로 제품전체에 적용될수 
없 다고 하더 라도 제 품의 모둘크기 의 부분들에는 적 용될 수 있 다는것 이 다. 

2. 증명 을 상세 설계 와 함께 전개하는것 은 정 확성 증명 을 리 용하지 않을 때보다 적은 
오유를 가진 제품을 개발하는데로 이 어 져 야 한다. 

3. 많은 갈은 프로그람작성 자가 상세설계 와 실행 을 모두 책 임진다면 흔히 있는 경 우 

와 마찬가지로 그 프로그람작성자는 상세설계가 정확하다고 확신할것이다. 제품 
에 대한 이러한 결정적인 태도는 보다 적은 오유를 가진 코드작성에로 이어 져 
야 한다. 


1 3. 9. 실시간설계기법 

6.4.4 에 서 설명한바와 같이 실시 간쏘프트웨어 는 장치적 인 시 간제 약 즉 어 떤 제 약이 
만족되지 않으면 정 보가 잃 어 진다는 성 질과 같은 시 간제 약에 의해 특징 지 어 진다. 특 
히 매개 입력은 다음 입력이 당도하기전에 수행되여야 한다. 이와 같은 체계의 한가지 
실례는 를퓨터조종핵 반응기 이 다. 핵의 온도와 반응기물준위와 갈은 입 력들은 콤퓨터 에 
련속적으로 보내 지는데 콤퓨터는 매 입력값을 읽고 다음입력이 오기전에 필요한 처리를 
진행 한다. 또 한가지 실례 는 콤퓨터조종집중치 료기 이 다. 여 기 에는 두가지 류형의 환자자 
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료가 존재 한다. 즉 매 환자의 심장박동, 체온, 혈압과 갈은 일상정보와 환자의 상태 가 경 
각에 이르렀다는것을 체계가 알았을 때의 비상정보가 있다. 이와 갈은 비상사태들이 발 
생하였을 때 쏘 프트웨 어는 한명 또는 그이상의 환자들에게서 오는 일상입력들과 비상사 
태관련입력들을 모두 처 리하여야 한다. 

많은 실시간체계들의 한가지 특성은 그것들이 분산된 하드웨어상에서 실현된다는것 
이 다. 실례 로 한대의 전투기 를 조종하는 쏘프트웨어 는 5대 의 콤퓨터상에서 실현될수 있 
다. 한대는 비행을 조종하고, 한대는 무기계통을 조종하며, 세번째는 전자대응수단을 위 
한것 이며，네번째 콤퓨터는 보조날개와 기관들과 갈은 비 행기장치들을 조종하며，다섯번 
째 를퓨터는 전투에서 전술방안을 제안한다. 하드웨어를 전적으로 믿을수는 없기때문에 
오동작하는 장치 를 자동적 으로 교체하는 반결 합콤퓨터 들을 추가할수 있 다. 이 와 갈은 체 
계의 설계 는 중요한 통신적 인 의미 를 가질뿐만아니 라 앞에서 설명한 류형의 시 간에 관한 
문제들이 체계의 분산성의 결과로써 발생하게 된다. 실례로 전투조건하에서 전술작성콤 
퓨터 는 조종기 에 상승할것 을 제 기하며 반면 에 무기 계 통콤퓨터 는 어 떤 특정한 무기 가 최 
량조건하에서 발사될수 있도륵 조종기에 급강하하도록 권고한다. 그러나 조종사는 조종 
간을 오른쪽으로 움직 이기 로 결심하며 따라서 비행기 가 지적된 방향으로 경사 지 어 비행 
하도록 비행장치콤퓨터에 신호가 전송되여 필요한 조절이 진행된다. 이 모든 정보들은 
비 행 기의 실제적운동이 제 안된 전술방안보다 모든 방법 에서 우위 를 차지하게 하는 방법 
으로써 처리되여야 한다. 더우기 비행기의 실제적운동은 새로운 제안들이 제안된 조건이 
아니 라 실제 적 조건들에 비 추어 공식 화할수 있도록 전술 및 무기 계 통콤퓨터 들에 중계되 여 
야 한다. 

실시간체계가 분산된 하드웨어상에서 실현되게 된다고 하자. 두개의 작용들이 하나 
의 자료항목을 배 타적 으로 리용하며 또 하나의 작용이 다른 자료항목들을 배 타적 으로 리 
용하게 되 는 경 우에 교착과 같은 정 황이 발생한다. 물론 교착상태 는 분산된 하드웨 어 상 
에서 실현되 는 실시 간체계 에서만 발생하는것은 아니 다. 그러 나 교착은 입 력의 순서 나 박 
자를 조종하지 않는 실시간체 계들에서 특별히 시끄러우며 정황은 하드웨어의 분산성으로 
하여 복잡해 진다. 교착상태외 에도 경쟁 조건들을 비롯한 다른 동기 화문제 들도 발생할수 
있 다. 자세한 내 용을 알기 위 하여 서 는 문헌 [Silberschatz and Galvin , 1998] 이 든가 다른 조 
작체계관련교재들을 참고할수 있다. 

이러한 실례들로부터 실시간체계의 실례와 관련한 중요한 난점은 시간제약들이 그 
설계에 의하여 만족된다는것을 확인하는것 이 라는것 이 명백해 진다. 즉 설계기법들은 그 
것 이 실현될 때 설계 가 요구되 는 속도로 들어 오는 자료를 읽 고 처 리할수 있 다는것 을 검 
사하기 위한 기구를 제공하여 주어야 한다. 더우기 설계에서 동기화문제들이 정확하게 
제기되였다는것도 보여 줄수 있어야 한다. 

를퓨터시대가 시작된 이 래 하드웨 어기술에서의 진보는 거의 모든 측면에서 쏘프트웨 
어 기술에서의 진보를 릉가하였 다. 그러 므로 앞에서 설명한 실시 간체 계 들의 모든 측면을 
조종할수 있는 하드웨 어는 존재하여 도 쏘프트웨 어설계 기 술은 상당히 뒤 떨어 져 있다. 실 
례로 제 11장과 제 12장에서 서술한 대다수의 명세서 작성기 법들은 실시간체계들을 명시 하 
는데 리용될수 있다. 그러나 쏘프트웨어설계는 아직 이러한 세련된 준위에 도달하지 못 
하였 다. 큰 진보는 이 룩되 였지 만 최 신성 에 있어서 는 명세작성 기술에서 도달된 성 과와는 
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대비할수 없다. 실시간체계를 위한 거의 모든 설계방법들을 선택할수 있는 기법이 전혀 
없기때문에 많은 실시간체계들을 경험적으로 리용하고 있다. 그러나 앞에서 서술한것과 
같은 실시간체계들을 설계하며 체계가 실현되기전에 매 실시간제약들이 만족되며 동기화 
문제들이 발생하지 않을것이라는것을 확정할수 있게 되려면 아직 멀었다. 

대 다수 실시 간설계 기 법들은 비 실시 간기 법들의 실시 간령 역 에 로의 확장이 다. 실례 로 
실시 간체 계 에 대 한 구조화된 개 발 ( SDRTS)[Ward and Mellor , 1985] 는 본질에 있어서 구조 
화체 계 분석 (11.3), 자료흐름분석 (13.3), 트랜 잭 션 분석 (13.4) 의 실 시 간쏘프트웨어 에 로의 확장 
이 다. 이 개 발기 법 은 실 시 간설 계 를 위한 한가지 요소를 포함하고 있 다. 레 비 ( Levi ) 와 아 
그라왈라 ( Agrawala ) 는 정보은페 (7.6) 의 개념에 기초하여 실시간방법들을 개발하였다 [Levi 
and Agrawala , 1990]. 앞에서 서술한바와 같이 유감스럽게 도 실시 간체 계의 최 신기 법 은 우 
리 가 바라는것만큼 진보하지 못하였다. 

그러 나 문헌 [ Stankovic , 1995] 에서 서 술하고 있는것 처 럼 이 정 황을 개 선하기 위 하여 
현재 상당한 노력을 기울여 연구를 진행하고 있다. 

13. 10 . 설계단계에서의 시험 

설계단계에서 시험의 목적은 설계 그자체의 정확성을 확인하는것과 함께 명세서가 
설계 에 정 확하고 완전하게 병합되 였다는것을 검증하는것 이 다. 실례로 설계 에 론리적 오유 
들이 없어야 하며 모든 대면부들이 정확히 정의되여야 한다. 설계에서의 모든 오유들을 
코드작성이 시작되기전에 발견하는것이 중요하다. 그렇지 않으면 그 오유를 수정하는데 
드는 비용이 상당히 높아 지게 될것이다. 설계오유들은 설계관통심사회의뿐아니라 설계 
검토에 의하여 발견될수 있다. 설계검토는 이 절의 나머지부분에서 론의되는데 설계관통 
심사회의에도 마찬가지로 주목을 돌려야 한다. 

제품이 트랜잭션을 위한것일 때 (13.4) 설계검토는 트랜잭션을 반영하여야 한다 
[ Beizer , 1990]. 모든 가능한 류형의 트랜잭션을 포함하는 검토계획이 작성되여야 한다. 심 
사자는 설계안의 매 트랜잭션들을 명세서와 관련시켜 그 트랜잭선들이 명세서로부터 어 
떻게 생성되는가를 보여 주어야 한다. 실례로 만일 응용제품이 자동출납기라면 하나의 
트랜잭션은 신용카드에 예금을 한다든가 또는 신용카드에서 자금을 대출한다든가와 같은 
손님 이 진행할수 있는 매 조작에 대 응한다. 다른 실례 들에서 명세서 와 트랜 잭 션사이 의 
대응은 필수적으로 1대 1 대응되지는 않는다. 실례로 교통신호등조종체계에서 만일 한대 
의 자동차가 수감구역 으로 들어 섬 으로써 조종체 계 가 어 떤 특정한 등을 15 s 내 에 붉은색 
으로부터 푸른색 으로 바꾸도록 결정하게 한다면 수감구역 으로부터 오는 이 두 신호들은 
무시될수 있다. 거꾸로 교통흐름량을 늘이기 위하여 수감구역에서 오는 하나의 신호가 
모든 교통신호들을 붉은색 에서 푸른색으로 바꾸도록 할수도 있다. 

검토를 트랜잭션구동검토에 제한시키면 설계자들이 명세서에서 요구되는 트랜 잭션실 
례들을 못 보고 지 나친 경 우를 발견하지 못하게 될 것 이 다. 극 단한 실 례 로서 교통신호등 
조종기에 대한 명세서들은 저녁 llh 부터 아침 6 h 사이에는 모든 신호등들이 한 방향에서 
는 노란색 으로 다른 방향에서는 붉은색 으로 켜지 게 된다는것을 명기할수 있다. 만일 설 
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계자들이 이 명기내용을 못 보고 지나치게 되면 저녁 llh 와 아침 6 h 에서의 박자발생트랜 
잭션은 설계에 포함되지 않게 될것이다. 그리고 이 트랜잭션들을 놓치게 되면 그것들은 
트랜잭선에 기 초한 설계 검 토에서 시 험되지 않게 될것 이 다. 그러 므로 트랜잭 션구동식 설 계 
검 토계 획을 작성하는것은 적 당치 않다. 명세서안의 설명 문들이 하나도 스쳐 지 났거 나 잘 
못 해석되지 않았다는것을 확인하는데서는 명세서구동검토가 역시 기본으로 된다. 

13. 11. 설계단계를 위한 CASE 도구 

앞절에서 설명한바와 같이 설계단계에서 한가지 중대한 국면은 설계문서가 명세서의 
모寒 측면들을 정확하게 병합하고 있다는것을 시험하는것이다. 그러므로 명세서와 설계 
문서에 모두 리용될수 있는 CASE 도구 즉 앞단 ( fronz - em /) 또는 상위 ( M / 少 er)CASE 도구들이 
요구된다(이 도구들은 실현，통합，유지 정 비 를 지 원하는 뒤단一 c 나«쐬 또는 하위 ( fewer ) 
CASE 도구들이 다.). 

많은 상위 CASE 도구들이 시 장에서 판매되고 있다. 보다 대중적 인것들로서는 Analyst/ 
Designer, Software through Pictures, System Architect 들이 다. 상위 CASE 도구들은 일 반적 으로 
자료사전을 중심에 두고 구축된다. 이 CASE 도구들은 사전안의 기록의 매 마당이 설계 
문서의 어디에서 언급되고 있는가 또는 설계문서의 매 항목이 자료흐름도에 반영된다는 
것을 검사할수 있다. 

더우기 대 다수 상위 CASE 도구들은 일관성검사기 를 병 합하고 있는데 이것 은 자료사 
전을 리용하여 설계안의 매 항목이 명세서에 선언되였으며 거꾸로 명세서안의 매 항목 
이 설계 에 나타난다는것을 결정한다. 또한 대 다수 상위 CASE 도구들은 화면구성 및 보고 
서 생 성프로그람들을 병 합하고 있 다. 즉 의 뢰 자는 어 느 항목들이 어 떤 보고서 에 또는 어 
떤 입력화면에 나타나게 되며 매 항목들이 어디서 어떻게 나타나게 되는가를 명시할수 
있다. 매 개의 항목을 고려하여 완전한 세 부들이 자료사전안에 있기때 문에 CASE 도구들 
은 보고서 를 인쇄하거 나 의 뢰 자의 요구에 따라 입 력화면 을 현시하기 위한 코드를 쉽 게 
생성할수 있다. 일부 상위 CASE 제품들은 평가 및 계획작성을 위한 관리도구들을 병합할 
수 있 다. 

객체지향설계 에 관하여 Together, Rose, Software through Pictures 들은 완전한 객체지향 
생명주기의 범위내 에서 이 단계를 지 원하여 준다. 

13. 12. 설계단계를 위한 척도 

설계의 측면들을 서술하기 위하여 각이한 척도들을 리용할수 있다. 실례로 모둘의 개 
수는 목적하는 제품의 크기에 대한 하나의 자연스러운 척도로 된다. 모둘의 응집도와 결합 
도는 오유통계량과 마찬가지로 설계의 질에 관한 척도로 된다. 다른 모든 류형의 검사와 
마찬가지로 설계검토기간에 발견된 설계오유의 개수와 류형에 대한 기록을 보관하는것은 
매우 중요하다. 이 정보는 제품의 코드검토기간과 련이은 제품들의 설계검토에서 리용된다. 

상세설계의 주기적복잡도 살은 2 분결정(술어)수에 1 을 더한 수이며 [McCabe, 1976] 
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또는 등가적으로 모둘에서의 가지의 개수이다. 주기적복잡도가 설계의 질에 대한 하나의 
척도로 된다는것 이 제시되 였다. MS \ 값이 작을수록 더 좋다. 이 척도의 우점은 계산하기 
쉽다는것이다. 그러나 이 척도는 하나의 고유한 문제점을 가지고 있다. 주기적복잡도는 
순전히 조종복잡도에 대한 측정값이며 자료의 복잡도를 무시하고 있다. 즉 M 은 어떤 표 
안의 값과 같이 자료에 의하여 구동되는 모둘의 복잡도를 재지 못한다. 실례 로 설계 자가 
C ++ 서고함수 toascii 를 모르고 사용자가 입력한 하나의 문자를 읽고 대응하는 ASCII 코드 
(0 과 127사이 의 옹근수)를 귀 환하는 모둘을 처 음부터 설계 한다고 하자. 이 모둘을 설계하 
기 위 한 한가지 방법 은 switch 명 령 에 의하여 수행 되 는 128개 의 가지 를 리용하는것 이 다. 
두번째 방법은 128개의 문자들을 ASCII 코드순서로 포함하고 있는 하나의 배렬을 만들고 
하나의 순환을 리용하여 사용자가 입 력 한 문자를 문자배 럴 의 매 요소와 비 교하는것 이 다. 
그러면 순환변수의 현재값은 대응하는 ASCII 코드이다. 이 두가지 설계는 기능상 등가이 
지만 각각 128과 1의 주기적복잡도를 가진다. 

구조화된 파라다임 이 리 용될 때 설 계 단계 에 대 한 어 떤 련관된 부류의 척 도는 구성방 
식설계를 하나의 방향그라프로 표현하는데 기초하고 있다. 이 방향그라프에서 모둘들은 
마디점으로 표시되고 모둘(절차와 기능호출)들사이의 흐름들은 호로써 표시된다. 어떤 모 
둘의 입 력 수(/뇨-떠는 그 모둘에 로의 흐름들의 개 수에 그 모둘이 접 근하는 대 역자료구조 
의 개 수를 더 한것 으로서 정 의 할수 있 다. 이 와 류사하게 출력 수(다«-0때는 그 모둘로부터 
나오는 흐름의 개 수에 그 모둘에 의하여 갱 신되 는 대 역자료구조의 개 수를 더한것 으로서 
정 의된다. 그러 므로 모둘의 복잡도는 길 이 X ( 입 력 수 X 출력 수) 2 에 의 해 주어 진다. 여 기서 길 이 
( length ) 는 모둘의 크기 에 대 한 측정값이 다. (9.2.1). 입 력수와 출력수의 정의 가 대 역 자료를 병 
합하고 있기때문에 이 척도는 자료의존요소를 가지고 있다. 그러나 경험은 이 척도가 주 
기적복잡도와 같은 보다 단순한 척도보다 더 좋은 복잡도측도로 되지 않는다는것을 보여 
주었 다 [ kitchenham , Pickard , and Linkman , 1990, Shepperd , 1990]. 

설계척도에 대한 론의는 객체지향파라다임이 리용될 때 보다 복잡하게 된다. 실례 
로 많은 클라스들은 전형 적 으로 여 러개의 작고 단순한 방법 들을 포함하기때 문에 한개 
클라스의 복잡도는 일 반적 으로 낮다. 더우기 앞에 서 지 적한바와 같이 주기 적복잡도는 
자료의 복잡도를 무시하고 있다. 자료와 작용들은 객체지향파라다임내에서 동등한 상 
대자이기때문에 주기적복잡도는 어떤 객체의 복잡성에 영향을 줄수있는 하나의 중요 
한 요소를 고찰하지 않고 있다. 그러 므로 주기 적복잡도로 병 합하는 클라스들에 대 한 
척도는 일반적으로 적게 리용된다. 

객체지 향설계 에 대 한 여 러 가지 척도들이 제 시되 였다. 례하면 문헌 [Chidamber and Ke 
merer , 1994] 에 제 시된 척도들이 다. 이 척도들과 기 타 척도들은 리 론적 및 실험 적 립 장에 
서 연구되 였 다 [Binkley and Schach , 1996; 1997; 1998]. 
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13. 13. 항공음식전문회사 실례연구: 
객체지향설계 


13.6 에서 서 술한바와 같이 객체지향설계 는 네단계 로 구성된다. 

1 단계 : 매 대본에 대한 호상작용들을 작성한다 예약에 대한 확장대본(그림 12-12) 의 
순차도를 그림 13-18 에 보여 주었다. 이 순차도는 대본안의 매 설명문을 취하여 련관된 
클라스들의 실 례 들사이 에 화살표를 그음으로써 작성 되 였 다. 
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보다 세부적 으로 말하면 먼저 그 대 본의 작용자들 즉 Passenger , Phone Operator , 
Air Gourmet database 가 결정 되였다. 

이 세개의 작용자들의 이름을 포함하고 있는 통들은 그림 13-18 의 상단에 배치되며 
수직2중선이 그려 진다. 이제 대본의 매 사건들이 조사되여 순차도에 들어 간다. 실례로 첫 
번째 사건에서 승객은 예약을 하기 위하여 교환수를 전화로 찾는다. 이 사건은 Passenger 
수직2중선으로부터 Phone Operator 수직2중선에 로 향하는 표식 1. request reservation 이 붙 
名 r 수평 화살표로 모형화된 다. 

순차도의 나머지부분들도 다른 클라스들에 대 한 순차도에서와 마찬가지로 간단하다. 
우편엽서의 반환과 조사에 대한 대본(그림 12-14) 의 협동도를 그림 13-19 에 보여 주었다. 
그림 13-18 의 순차도와 마찬가지로 협동도를 구성 할 때의 첫 단계는 확장대본(그림 12- 
14) 을 조사하고 작용자들을 결 정하는것 이 다. 이 경 우에 작용자들은 Air Gourmet Staff 
Member , Passenger , Air Gourmet databa 期 로 찾아 냈다. 이 작용자들이 그림 13-19 에 그 
려 진다. 다음으로 매 사건들이 조사되며 선도에 들어 간다. 사건 1에서 항공음식전문회 
사의 한 직원이 특별식 사를 받은 매 승객 들에 게 우편엽서 를 보낸 다. 먼저 Air Gourmet 
Staff Member 와 Passenger 사이에 하나의 직선이 그려 진다. 그다음 회사직원이 우편엽서 
를 승객 에 게 보낸 다는것 을 지 적 하기 위하여 하나의 표식 불은 화살표가 삽입 된 다. 

1 . send postcard - 

세 - 2. return postcard 

Passenger 


3. record meal quality 


Air Gourmet database 


그림 13-19. 엽서의 반환과 조사에 대한 대본의 협동도(그림 12-14) 

두번째 사건은 그 우편엽서를 받은 승객이 엽서에 답변을 채워 넣고 그것을 회사직 
원에게 돌려 보내는것이다. 이 사건은 표식 2. return postcard 가 붙은 역방향화살표로 지 
적된 다. 

세번째 사건은 회 사직 원이 그 엽서 를 받고 봉사 받은 특별식 사에 대 한 승객의 견해 
를 반영 하기 위하여 련관된 비 행 기록을 갱 신하는것 이 다. 항공음식전문회 사직원을 표시하 
는 그림기 호 (/ con ) 와 항공음식전문회 사자료기 지 를 표시하는 통사이에 하나의 수직 선 이 그 
려 진다. 마지막으로 표식 3. record meal quality 가 붙은 하나의 화살표가 추가된다. 나머 
지 호상작용도들도 이와 같은 방법으로 구성된다. 
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그림 13-20. 항공음식전문회사제품의 C ++ 실현을 위한 세부클라스도(계속) 


2 단계:세부클라스도를 구성한다 C ++ 실현을 위한 세 부클라스도를 그림 13-20 _ 
주며 Java 실현을 위 한 세부클라스도는 그림 13-21 에 보여 준다. 두 그림 사이 의 
차이 는 Java 가 날자들을 처 리 하기 위 한 내 장된 클라스들 즉 java . text.Dateformat - 
util.Calendar 를 가지고 있으며 반면에 C ++ 실현에서는 사용자정의클라스 Date 가 
다는것 이 다. 또 한가지 차이 는 Java 는 순수한 객체지향언어이며(즉 Java 프로 
클라스도의 모임이다.) 반면에 C ++ 는 함수들을 지원하고 있다는것이다. 이러한 
관련 하여 클라스 Air Gourmet Application 은 C ++ 함수 main 에 대응하며 Air G 
Utilities 는 C ++ 편의함수를에 대 유한다. 












>rint () 


abstract 

get qualifications () 
qualifies for report () 
print record () 
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그림 13-21. 항공음식전문회사제품의 Java 실현을 위한 세부믈라스도(계속) 


제 품에 대 한 방법 들은 각이한 호상작용선도들에 나타난다. 설 계 자의 과제 는 매 방법 
어 느 클라스에 할당되 여 야 하는가를 결정하는것 이 다. 

항공음식전문회 사제 품의 경 우에 클라스도에 로의 방법 들의 할당은 단순하다. 실려' 
3■법 get passenger ID 는 명백히 클라스 Passenger 에 속한다. 

3단계:객체들과 그의 의뢰자들에 으 I 하여 제품을 설계 한다 00 D 의 세번째 단계 는 13/ 

보여 준것 처 럼 객 체 들과 그 의 뢰 자들에 의하여 제 품을 설 계하는것 이 다. 의 뢰 자 - 7 J 
계 는 그림 13-22( C ++ 실현)와 그림 13-23( Java 실 현)에 의 뢰 자-객 체관계 선도들은 머 
카드들을 조사하며 다른 클라스들의 어 느 방법 들이 그 콜라스의 방법 들에 의하여 J 
는가를 결 정하는것 으로써 구성 된 다. 일 반적 으로 만일 CRC 카드들이 만들어 지 지 일 






.들이 이 목적에 리용될수 있다. 항공음식전문회사제품의 신속원형(부 
표구동설 계 가 실현가능하다는것 을 보여 주었 다. 주차림 표는 사용자가 
가운데 서 어 느것 을 인쇄하겠는가를 선택할수 있게 한다. 그림 13-22 와 
반영되여 있다. 보여 준다. 이것들은 UML 의 선도가 아니다. 경험에 
은의 선도들이 제 품의 각이한 부분들이 어 떻게 서 로 조화되는가를 리해 
갔으며 특히 상세설계를 구성하기 쉽게 할수 있기때문에 이 선도들을 


























13. 14. 설계단계에서의 난관 


11.6 과 12.9 에 서 지 적한바와 같이 명세작성단계 에 서 너 무 많은것 을 하지 않는것 이 중 
요하다. 즉 명세작성 림 은 설계 단계 의 부분들을 때 이 르게 시 작하지 말아야 한다. 설계단 
계에서 설계 림은 다음의 두가지 방식으로 잘못해 나갈수 있다. 즉 너무 많이 하거나 너 
무 적 게 하는것 이 다. 

그림 13-7 의 PDL 이 아니 라 C ++ 또는 Java 로 작성 하려는 유혹은 아주 강하다. 즉 상세 
설계 를 의 사코드로 기 술하는것 대 신에 설계 자가 모둘을 거의 모두 코드작성할수도 있다. 이 
것 은 모둘의 륜곽을 서 술하는것 보다 그것 을 작성하는데 더 많은 시 간이 들게 하며 설계 에 
서 오유가 발견되는 경우에 그것을 수정하는데 더 오랜 시 간이 걸 리게 한다(그림 1-5 를 보 
시오.). 명세서작성림과 마찬가지로 설계림의 성원들은 자기들에게 필요한것보다 더 많은것 
을 하려 는 충동을 억 제하여 야 한다. 

동시 에 설 계 림 은 너 무 적 게 설 계하지 않는데 도 주의 를 돌려야 한다. 그림 13-6 의 표 
형식의 상세설계를 고찰하자. 만일 설계 림 이 바쁘다면 상세설계를 설명칸으로 수축하기 
로 결심할수도 있다. 지 어는 프로그람작성 자들은 자기 들이 상세설계 를 진행 하기 로 결심 
할수도 있다. 이러한 결심들은 모두 잘못되였다. 상세설계를 진행하는 선차적인 리유는 
모든 대면부들이 정확하다는것을 확인하는것이다. 설명통 그자체가 이 목적에 부합되지 
않는다. 상세설계 가 전혀 도움이 안되 는것은 아니 다. 그러므로 설계 단계에서의 한가지 난 
관은 설계 자들이 정 확한 작업 량을 수행하도록 하는것 이 다. 

이 밖에 보다 중요한 한가지 난관이 있다. 론문《은총탄은 없다.》 [ Brooks , 1986] 에서 
브룩스 ( Brooks ) 는 이 른바 설계대 가 즉 설계 림 의 다른 성 원들보다 훨씬 뛰 여 난 설계 가 
의 결여 를 비 난하고 있 다. 브룩스의 견해 에 의하면 쏘프트웨 어프로젝 트의 성 공은 그 설 
계림이 설계대가에 의하여 지도되는가에 결정적으로 의존한다. 훌륭한 설계는 다음의 사 
실을 가르쳐 줄수 있다. 즉 큰 설계는 설계대 가에 의 해서 만 작성될수 있는데 설계대 가들 
은《매우 드물다.》. 

그러 므로 한가지 난관은 설계대 가들을 양성 하는것 이 다. 그들을 될수록 빨리 찾아 내 
서(가장 훌륭한 설계가들이 반드시 가장 경험있는것은 아니다.) 어떤 책임자에게 배치하 
여 설계대 가들의 조수들과 마찬가지의 공식 적 인 교육을 주며 다른 설계 가들과 호상작용 
할수 있도록 하여야 한다. 


O 야 

-U- 一 I 

설계 단계 는 구성 방식 설계，그다음 상세 설계 로 이 루어 진다 (13.1). 세 가지 기 본설계방 
법 즉 작용지향설계 (13.2), 자료지향설계(13.5)，객체지향설계 (13 .句가 있다. 작용지향설계의 
두가지 실례들인 자료흐름분석 (13.3) 과 트랜잭 션분석 (13.4) 이 서 술된다. 객체지향설계를 
13.7 의 승강기문제 에 적 용한다. 상세 설계 를 위한 기 법 들이 13.8 에 제 시된다. 실시 간체 계 는 
13.9 에서 설명된다. 13.10 에서 설계의 시험을 론의한다. 설계단계에서의 CASE 도구들과 척 
도들은 13.11 과 13.12 에 서 각각 론의한다. 이 장은 항공음식 전문회 사 실 례연구 (13.13) 와 
설계 단계에서의 난관에 대 한 론의 (13.14) 로 결속된다. 




보 충 


자료흐름분석 과 트랜 잭 션분석 은 문헌 [Gane and Sarsen , 1979, and Yourdon 
Constantine , 1979] 에 서술되여 있다. 잭슨 ( Jackson ) 의 기법은 문헌 [ Jackson , 1975] 에서 
서술하고 있 다. 워니오 ( Wamier ) 의 연구에 흥미를 가지는 독자들에게는 문헌 [ Wamier , 
1976] 이 기본문헌으로 되고 있다. 오르 ( Orr ) 의 연구방법에 대하여서는 문헌 [ Orr , 1981], 
객체지향설계와 관련한 정보는 문헌 [ Wirfs - Brock , Wilkerson and Wiener , 1990; Coad and 
Yourdon , 1991 b ; Shlaer and Mellor , 1992; and Jacobson , Booch and Rumbaugh , 1999] 에서 
찾아 볼수 있다. 객 체지향설계 와 관련한 여 러 가지 기 법 들에 대 한 비 교는 문헌 [Monarchi 
and Puhr , 1992, and Walker , 1992] 에서 서 술하고 있 다. 객 체지향과 구조화설계 기 법사이 의 
비 교는 문헌 [Fichman and Kemerer , 1992] 에서 보여 주었다. 

형식적인 설계기법들은 문헌 [ Hoare , 198刀에서 서술하였다. 

설계과정의 검토와 관련한 초기론문은 [ Fagan , 1976] 이 다. 검토기 법과 관련하여 그 후 
의 발전적인 결과는 문헌 [ Fagan , 1980] 에서 서술하여 주었다. 사용자대면부 설계를 시험 
하기 위한 관통심 사회 의 의 리용에 대 하여 서 는 문헌 [ Bias , 1991] 에 서 서 술하였 다. 실 시 간설 
계와 관련한 특정 한 기 법은 문헌 [Ward and Mellor , 1985; Levi and Agrawala , 1990; and 
Cooling , 199 刀에서 찾아 볼수 있 다. 네 개의 실시간설계기법의 비교에 대하여서는/£五五 
Computer 1995년 6월호와 함께 문헌 [Kelly and Sherif , 1992] 에서 찾아 볼수 있다. 분산체 
계 의 설계 에 대 하여 서 는 문헌 [ Kramer , 1994] 에 서 서 술하여 주 SX 다. IEEE Software 1992년 
9월/10월호에는 구성방식설계와 관련한 많은 기사들이 들어 있다. 

설 계 단계 를 위한 척 도에 대 하여 서 는 문헌 [Henry Kafura , 1981; Brandi , 1990; Henry 
and Selig , 1990; and Zage and Zage , 1993] 에서 서 술하고 있 다. 객체지 향설계의 척도에 대 
하여 서 는 문헌 [Chidamber and Kemerer , 1994, and Binkley and Schach , 1996] 에 서 론의 하 
였 다. 

쏘프트웨어명세작성 및 설계에 관한 국제토론회 회보에서는 설계기법에 대한 가치 
있는 정보들을 제공하고 있다. 

문 제 

13.1. 문제 11.6 에 대 하여 먼 저 DFD 를 작성하면서 자료흐름분석 을 리 용하여 
은행 계 산서 의 정 확성 여 부를 결 정 하는 제 품을 설 계 하시 오. 

13.2. 프랜 잭 션 분석 을 리용하여 ATM (문제 8.9) 을 조종하기 위한 쏘프트웨어 를 설 계 
하시 오. 이 단계 에 서 오유조종능력 은 생 략하시 오. 

13.3. 이제 문제 13.2 에 대 하여 작성하는 설계를 조사하고 오유조종을 수행 하기 위한 
모둘들을 추가하시 오. 결과설계 를 주의 깊게 조사하고 모둘들의 응집 도와 결 합도를 결정하 
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시 오. 그림 13-10 에 묘사된것 과 같은 정 황에 주의 하시 오. 

13.4. 상세 설계 를 묘사하기 위 한 두개 의 서 로 다른 기 법들이 13.3.1(그림 13-6 과 13- 
7) 에 제시된다. 두 기법을 비 교대조하시오. 

13.5. 자동서고순환체 계 (문제 11. 8) 에 대 한 자료흐름도를 먼 저 작성하면서 

자료흐름분석 을 리용하여 순환체 계 를 설 계하시 오. 

13.6. 트랜 잭 션 분석 을 리 용하여 문제 13.5 를 반복하시 오. 두 기 법가운데 서 어 느것 이 
보다 적 당하다고 생각하는가? 

13.7. 자동서고순환체 계(문제 12.2) 에 대 한 객체지향분석 으로부터 시 작하여 

객체지향설계 를 리용하여 서 고체 계 를 설계하시 오. 

13.8. 객체지향설계 를 리용하여 ATM 쏘프트웨 어(문제 8.9) 를 설명 하시 오. 

13.9. (과정 안상 목표) 문제 11.5 또는 12.9 에 대한 명세서를 먼저 작성하고 브로드랜 
즈지역 아동병원제품(부록 1) 을 설계하시오. 지도교원이 규정한 설계기법을 리용하시오. 

13.10. (실 례 연구)자료흐름분석 을 리 용하여 항공음식 전문회 사제 품을 재 설 계 하시 오. 

13.11. (실 례연구)트랜잭 션분석 을 리용하여 항공음식전문회 사제 품을 재 설계하시 오. 

13.12. (실례연구) 부록 8과 부록 9의 상세설계들은 표형 식 으로 제시된다. 자신 이 
선택 한 PDL (의 사코드)을 리 용하여 설 계 를 다시 제 시 하시 오. 

어 느 표현 이 더 좋은가? 그 대 답과 리유를 주시 오. 

13.13. (쏘프 트웨 어 공학독본) 교원 은 문헌 [ Stolper , 1999] 의 복제본을 배 포할것 이 다. 
고전적파라다임을 리용하고 있는 어떤 개 발기 업체 에 객체지향파라다임 을 도입하는것과 
관련한 당신의 견해는 무엇인가? 


446 



참고문헌 


[Beizer, 1990J B. Beizer, Software Testing Techniques, 2nd ed., Van Nostrand Reinhold, 

New York, 1990. 

[Bias ， 1991] R. Bias, ^Walkthroughs: Efficient Collaborative Testing，” IEEE Software 8 
(September 1991), pp. 94-95. 

[Binkley and Schach, 1996] A. B. Binkley and S. R. Schach, “A Comparison of Sixteen 
Quality Metrics for Object-Oriented Design/' Information Processing Letters 57 (No. 6, 
June 1996), pp. 271-75. _ 

[Binkley and Schach, I997J A. B. Binkley and S. R. Schach, “Toward a Unified Approach 
to Object-Oriented Coupling,” Proceedings of the 35th Annual ACM Southeast 
Conference, Murfreesboro, TN，April 2-4, 1997, pp. 91-97, 

[Binkley and Schach, 1998] A. B. Binkley and S. R. Schach, “Validation of the Coupling 
Dependency Metric as a Predictor of Run-Time Failures and Maintenance Measures,” 
Proceedings of the 20th International Conference on Software Engineering, Kyoto, 
Japan, April 1988, pp. 542-55. 

[Brandi, 1990] D. L. Brandl, “Quality Measures in Design: Finding Problems before 
Coding，’’ ACM SIGSOFT Software Engineering Notes 15 (January 1990), pp. 68-72. 

[Brooks, 1986] F. P. Brooks, Jr” “No Silver Bullet，’’ in: Information Processing ’86, 

H.-J. Kugler (Editor)，Elsevier North-Hoi land. New York ， 1986. Reprinted in IEEE 
Computer 20 (April 1987), pp. 10-19. 

[Chidamber and Kemerer, 1994] S. R. Chidamber and C. F. Kemerer, “A Metrics Suite for 
Object Oriented Design，，’ IEEE Transactions on Software Engineering 20 (June 1994), 
pp. 476-93. 

[Coad and Yourdon, 1991b] R Coad and E. Yourdon, Object-Oriented Design, Yourdon 
Press, Englewood Cliffs, NJ, 1991. 

[Cooling, 1997] J. E. Cooling ， Real-Time Software Systems: An Introduction, Van Nostrand 
Rein hold. New York, 1997. 

[Fagan, 1976] M. E. Fagan, “Design and Code Inspections to Reduce Errors in Program 
Development，” IBM Systems Journal 15 (No. 3, 1976), pp. 182-21 

[Fagan, 1986| M. E. Fagan, “Advances in Software Inspections，’’ IEEE Transactions on 
Software Engineering SE-12 (July 1986 )， pp. 744-51. 

[Fichman and Kemerer, 1992J R. G. Fichman and C. R Kemerer, “Object-Oriented and 
Conventional Analysis and Design Methodologies: Comparison and Critique,” IEEE 
Computer 25 (October 1992), pp. 22-39. 

[Flanagan and Loukides ， 1997] D. Flanagan and M. Loukides, Java in a Nutshell: A 
Desktop Quick Reference' 2nd ed, O’Reilly and Associates, Sebastopol, CA, 1997. 

[Gane and Sarsen, 19791 C Gane and T, Sarshn, Structured Systems Analysis: Tools and 
Techniques, Prentice Hall, Englewood Cliffs, NJ, 1979. 

[Goldberg and Robson, 1989] A. Goldberg and D. Robson, Smalltalk:-80: The Language, 
Addison-Wesley, Reading, MA ， 1989. 

[Henry and Kafura ， 1981] S. M. Henry and D. Kafura, “Software Structure Metrics 
Based on Information Flow，” IEEE Transactions on Software Engineering SE-7 
(September 1981 )， pp. 510-18. 

[Henry and Selig ， 1990] S. Henry and C. Selig, “Predicting Source-Code Complexity at the 
Design Stage,” IEEE Software 7 (March 1990), pp. 36-44. 

[Herbsleb and Grinter, 1999] J. D. Herbsleb and R. E, Grinter ， “Architectures ， 
Coordination, and Distance: Conway’s Law and Beyond，” IEEE Software 16 
(September/October 1999) ， pp. 63-70. 

[Hoare, 1987] C. A. R. Hoare, “An Overview of Some Formal Methods for Program 
Design，” IEEE Computer 20 (September 1987), pp. 85-91. 


447 




[ISO/IEC 8652, 1995] “Programming Language Ada: Language and Standard Libraries,” 

ISO/IEC 8652, International Organization for Standardization, International 
Electrotechnical Commission, Geneva, 1995. 

[Jackson, 1975] M. A. Jackson, Principles of Prc^ram Design, Academic Press. New York. 1975. 

[Jacobson, Booch, and Rumbaugh, 1999] J. Rumbaugh, G. Booch, and L Jacobson, The 
Unified Software Development Process, Addison Wesley, Reading, MA, 1999. 

[Kelly and Sherif, 1992] J. C. Kelly and J. S. Sherif, “A Comparison of Four Design 

Methods for Real-Time Software Development，” Information and Software Technology 
34 (February 1992), pp. 74-82. 

[Kitchenham, Pickard, and Linkman, 1990] B. A* Kitchenham, L M ‘ Pickard, and 

S ， J, Linkman, S4 An Evaluation of Some Design Metrics/’ Software Engineering Journal 
5 (January 1990) ， pp. 5058. 

[Kramer ， 1994] J. Kramer, “Distributed Software Engineering,” Proceedings of the 16th 
International Conference on Software Engineering, Sorrento* Italy, May 1994 ， 
pp. 253-63. 

[Levi and Agrawala, 1990] S.-T. Levi and A. K. Agrawala, Real Time System Design, 
McGraw-Hill, New York, 1990. 

[McCabe, 1976] T. 上 McCabe ， ”A Complexity Measure，’’ IEEE Transactions on Software 
Engineering SE-2 (December 1976) ， pp. 308-20. 

[Meyer, 1992b] B. Meyer ， Eiffel: The Language, Prentice Hall，New York, 1992. 

[Monarchi and Puhr, 1992] D. E. Monarchi and G. I. Puhr, “A Research Typology 
for Object-Oriented Analysis and Design，” Communications of the ACM 35 
(September 1992), pp. 35 나 7. 。 

[Orr, 1981] K. Orr, Structured Requirements Definition, Ken Orr and Associates ， Inc., 

Topeka ， KS, 198L 

[Shepperd, 1990] M. Shepperd, “Design Metrics: An Empirical Analysis，” Software 
Engineering Journal 5 (January 1990) ， pp- 3-10- 

[Shlaer and Mellor, 1992] S, Shlaer and S, Mellor, Object Lifecycles: Modeling the World 
in States, Yourdon Press, Englewood Cliffs ， NJ, 1992. 

[Silberschatz and Galvin ， 1998] A. Silberschatz and P. B. Galvin, Operating System 
Concepts, 5 th ed., Addison-Wesley, Reading, MA ， 1998. 

[Stankovic, 1997] J. A. Stankovic ， “Real-Time and Embedded Systems" in: The Computer 
Science and Engineering Handbook, A. B. Tucker, Jr. (Editor-in-Chief), CRC Press, 

Boca Raton ， FL ， pp. 1709-24. 

[Stolper, 1999] S, A. Stolper, “Streamlined Design Approach Lands Mars Pathfinder；' IEEE 
Software 16 (September/October 1999 》， pp. 52 — 62. 

[Stroustrup ， 1991] B. Stroustrup, The C+4- Programming Language, 2nd ed .， 

Addison-Wesley, Reading, MA ， 1991. 

[Walker, 1992] I. J. Walker, “Requirements of an Object-Oriented Design Method，’’ 

Software Engineering Journal 7 (March 1992) ， pp. 102—13. 

[Ward and Mellor, 1985] P. T* Ward and S. Mellor, Structured Development for Real-Time 
Systems, Volumes 1， 2 and 3, Yourdon Press, New York, 1985. 

[Warnier, 1976] J ， D. Warnier, Logical Construction of Programs, Van Nostrand Reinhold, 

New York, 1976. 

[Wirfs-Brock, Wilkerson, and Wiener, 1990J R. Wirfs-Brock, B. Wilkerson, and 

L. Wiener, Designing Object-Oriented Software, Prentice Hall, Englewood Cliffs ， NJ, 

1990. 

[Yourdon and Constantine, 1979] E. Yourdon and L. L. Constantine, Structured Design: 
Fundamentals of a Discipline of Computer Program and Systems Design ， Prentice Hall, 
Englewood Cliffs ， NJ, 1979. 

[Zage and Zage, 1993] W. M. Zage and D. M. Zage, “Evaluating Design Metrics on Large- 
Scale Software" IEEE Software 10 (July 1993), pp. 75-81. 


448 








제 1 4장. 실 현 단 계 


실현은 상세설계를 코드로 넘기는 과정이다. 어떤 개별적인 사람에 의하여 실현이 
수행될 때 그 과정은 비교적 잘 리해된다. 그러나 현재 대부분의 실천적인 제품들은 너 
무 방대하기때문에 한명의 프로그람작성자가 주어 진 시간내 에 실현하기 어렵 다. 그대 신 
제품은 그 제품의 각이 한 부분들에 대하여 동시에 작업 하는 개 발림 에 의 하여 실현된다. 
이것을 협동프로그람작성 初-功 이라고 부른다. 이 장에서는 협동프로 

그람작성과 관련된 문제들이 론의된다. 

14 . 1 . 프로그람작성언어의 선택 

대부분의 경우에 실현을 위하여 어느 프로그람작성언어를 선택하겠는가 하는 문제는 
단순하게 제기되지 않는다. 의뢰자가 어떤 제품이 Smalltelk 로 작성되기를 바란다고 하자. 
개발림 의 견해 로서 는 그 제 품에 Smalltalk 가 전혀 부합되 지 않을수 있 다. 이 와 같은 견해 
는 의뢰자에게 적합치 않다. 그러면 개발기업체의 관리자측에게는 두개의 선택만이 존재 
하는데 그것은 그 제품을 Smalltalk 로 실현하든가 그 주문을 거절하는것 이 다. 

이 와 류사하게 제 품이 어 떤 특정한 콤퓨터 상에 서 실 현되 여 야 하며 또 그 를퓨터 에 서 
리용할수 있는 유일한 언어 가 아쌤블리 어라고 하면 거기 에는 다른 선택 이 없다. 그 콤퓨터 
상에서 동작하는 임 의의 고급언어 를 위한 를파일 러 가 아직 작성 되지 않았거 나 관리 자측이 
규정 된 콤퓨터 를 위한 새 로운 C++ 콤파일 러 를 사기 위하여 돈을 지 불할 준비 가 되 여 있지 
않는것 으로 인하여 기 타 다른 언어 를 리용할수 없 다면 프로그람작성언어 의 선택 에 관한 
론의는 적당하지 않다. 

보다 흥미 있는 문제는 다음과 갈다. 어떤 계 약서 가 제품이 《가장 적 당한》프로그 
람작성언어 로 실현된다는것 을 명 시 하고 있다. 어 느 언어 가 선택 되 여 야 하는가? 이 문제 
에 답변하기 위하여 다음과 갈은 대 본을 고찰하자. QQQ 회 사는 25년 이 상 COBOL 제 품을 
작성하여 왔다. 대 부분의 중간급프로그람작성자로부터 쏘프트웨어 의 부책 임 자에 이 르기 
까지 QQQ 회사의 200여명의 직원들이 COBOL 전문지식을 가지고 있다. 무엇때문에 지구 
상에서 가장 적절한 프로그람작성언어가 COBOL 이외의것으로 되여야 하는가? 어떤 새로 
운 언어 례하면 Java 의 도입은 새 로운 프로그람작성 자들을 고용하든가 최소한 현재의 직 
원들이 집 중적 으로 재 교육되 여 야 한다는것 을 의 미하게 된 다. 관리 자측은 Java 교육에 자금 
과 노력을 모두 투자하면서 미 래의 제품들이 Java 로 작성되 여 야 한다고 결심할수도 있다. 
그러 나 현존 COBOL 제품들도 모두 유지정비되여야 한다. 그렇게 되면 두가지 부류의 프 
로그람작성 자들 즉 COBOL 유지 정 비 를 위한 프로그람작성 자들과 새 로운 응용제 품들을 작 
성 하기 위 한 Java 프로그람작성 자들이 존재 하게 될것 이 다. 부당하게도 유지정 비는 거의 언 
제 나 새 로운 응용프로그람을 작성하는것 보다 렬 등하다고 간주되 고 있다. 그러 므로 
COBOL 프로그람작성자들은 분명히 불행한 처지에 놓이게 된다. 이러한 불행들은 Java 프 
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L 그람작성 자들이 단기보수를 받기 때 문에 COBOL 프로그람작성 자들보다 더 많은 보4 
!■게 된다는 사실로부터 생긴다. 비록 QQQ 가 COBOL 을 위한 뛰여 난 개발도구들을 
1고 있다 할지 라도 적 당한 Java 도구들은 물론 Java 콤파일 러 를 구입하여 야 한다. 이 새 
r 프로그람들을 실행 하기 위하여 추가적 인 하드웨 어들을 구입하거 나 빌러 야 한다. 이 
L 가장 심 각한 문제 는 QQQ 가 COBOL 에 대 한 많은 인적 및 시 간적 전문지 식 을 축적 히 
느며 이러한 전문지식들은 어떤 점의 오유가 화면에 출현하였을 때 무엇을 하며 콤피 
1의 급격한 변동을 어떻게 다루겠는가와 같이 수동적 인 경험에 의해서만 엄 어 질수 
f 는것이다. 믿건대 《가장 적합한》프로그람작성언어는 오직 COBOL 인것 같다. 임의 
f 른 언어의 선택은 그에 드는 비용의 견지로 보나 직원들의 사기를 떨구어 불충분한 
!의 코드를 만들어 내게 된다는 견지로 보면 재정적인 자살행위로 될것이다. 

알고 싶 a @제 

다른 모든 프로그람작성언어 를 합친것보다 더 많은 원천들이 COBOL 토서 직 S 되 였 
다. 본래 COBOL 은 그것 이 DoD 의 제 품이 기 때 문에 가장 광범하게 리 용되 였다. 죽，. 해 군 
소장 그레 이 스 머 레이 호퍼 (Grace Murray Hopper) 의 지도밑에 개발된 COBOL 은 .960 년 
DoD 에 의 하여 인중되 였 다. 그이 후부터 DoD 는 장치 가 COBOL 를파일 러 를 가지 고 ； 지 않 
는 한 자료처 리 응용을 위하여 그 장치 를 구입하지 않았다. DoD 는 지 금도 그러하; 만 세 
계 최대의 를퓨터하드웨 어구입자였으며 1960 년대 에 DoD 쏘포르웨어의 상당한 부분- ■이 자 
료처리를 목적으로 작성되였다. 그 결과 COBOL 콤파일러쓿 사실상 매 를퓨터에 대하여 
선 차적 으로 작성 되 였 다. 이 와 같은 COBOL 의 광범한 응용은 그에 대 한 유일 한 대 .언어 
가 아셈 블리 어였던 시대에 COBOL 이 세계적으로 가장 대중적 인 프로그람작성업로 되 
게 하였다. 

C, C 과, Java 4 세대 언어 들과 갈은 언어 들은 새 로운 응용들에서 의심 할바없이 대중성 
이 중가되고 있다. 그러나 유지정비는 여전히 중요한 쏘프트웨어활동이며 이러한 누지정 
비는 현존 COBOL 쏘프트웨어 에서 수행되 고 있다. 한마디 로 말하면 DoD 는 자기의 첫 프 
로그람작성언어 COBOL 을 통하여 세 계의 프로그람계 에 자기의 이름을 남기 였다. 

COBOL 이 대 중성 을 가지 게 된 또 한가지 리유는 COBOL 이 흔히 자료처 리 제4 ■을 실 
현하기 위한 가장 좋은 언어 로 되 기때문이 다. 특히 COBOL 은 일반적 으로 자료문; 가 포 
함되는 경우에 선택하게 되는 언어이다. 재정장부들은 잔고가 없이 깨끗이 맞아 1 어 져 
야 하며 따라서 둥그러 기 오유들이 끼 여 드는것 이 허 락될수 없 다. 그러 므로 모든 계_ 江들은 
옹근수산수연산으로써 수행되여 야 한다. COBOL 은 대 단히 # 수들(즉 백만딸라)<= 대 한 
산수연산을 지원한다. 그밖에 COBOL 은 매우 작은 수들을 다룰수 있다. 은행규칙들- - 적어 
도 소수점 4 자리까지의 센트에 해 당한 리 자계산을 할것을 필요로 하는데 COBOL 은 기러한 
산수연산을 매우 쉽게 할수 있다. 마지막으로 COBOL 은 가장 좋은 형식과 정렬방법 1 리고 
모든 3 세대언어들이 가지고 있는 보고서생성프로그람들을 가지고 있다. 이러한 모든 리유로 
하여 COBOL 은 자료처 리 제 품을 실현하기 위한 하나의 훌륭한 선택언어 로 된다. 

8.7.4 에서 언급한바와 같이 지금 거의 완성 단계 에 이 른 COBOL 언어표준은 화체지 
향언어를 위한것이다. 이러한 표준은 틀림없이 COBOL 의 대중성을 더욱 높여』게 될 




그러 나 QQQ 회 사의 최 신프로젝트에 가장 적 합한 프로그람작성언어는 사실 COBOL 이 
아닌 어떤 다른 언어 일수도 있다. COBOL 이 세 계적 으로 가장 광범히 리용되 는 프로그람 
작성언어로서의 지위를 차지 하고 있음에도 불구하고(우의 《 알고 싶은 문제》를 보시오.) 
COBOL 은 다만 한가지 부류의 쏘프트웨어제품 즉 자료처 리응용프로그람에 적 합하다. 만 
일 QQQ 회 사가 이 부류밖의 쏘프트웨어 제 품들을 요구한다면 COBOL 은 곧 자기 의 인기 를 
잃게 된다. 실례로 QQQ 가 인공지능기술을 리용하여 지식에 기초한 제품을 구성하려고 
한다면 Lisp 와 같은 AI 언어가 리용될것이며 COBOL 은 AI 응용에 전혀 적합치 않다. 만일 
대규모통신쏘프트웨어를 구성하게 되는 경우에는 QQQ 가 전 세계에 분포된 수백여개의 
지부들과 위성을 통해 결합될것이 요구되기때문에 Java 와 같은 언어가 COBOL 보다 훨씬 
더 적합하다고 판명될것이다. 만일 QQQ 가 조작체계，콤파일러, 련결편집프로그람과 같은 
체 계쏘프트웨어 를 작성하는 임 무를 수행하게 된 다면 COBOL 은 거 의 확정 적 으로 적 합치 
않다. 만일 QQQ 가 국방계 약에 종사하기로 결심한다면 관리 자측은 COBOL 이 실시 간내 장 
쏘프트웨어 에 리용될 수 없 다는것 을 곧 발견 하게 될 것 이 다. 

어느 프로그람작성언어가 흔히 리용되겠는가에 관한 론점은 비용 대 리득분석 (5.2) 을 
리용하여 결정될수 있다. 즉 관리자측은 COBOL 을 리용하는것으로써 현재와 미래에 얻 
게 될 리득과 함께 COLOL 실현에 드는 비용을 계산하여야 한다. 이러한 계산을 고찰하 
는 매 언어 에 대 하여 반복하여 야 한다. 예 상리득 즉 타산리 익 과 타산비 용의 차가 가장 
큰 언어 가 적 당한 실현언어 로 된다. 어 느 프로그람언어 를 선택하겠는가를 결정 하기 위한 
또 한가지 방법 은 위 험분석 을 리용하는것 이 다. 고찰하는 매 언어 에 대 하여 잠재 적 인 위 
험과 그것을 해소하는 방법들을 기록한 목록을 작성한다. 전반적 인 위험 이 가장 작은 언 
어가 선택되게 된다. 

현재 쏘프트웨 어개 발기 업체는 하나의 객체지향언어 즉 임의의 객체지향언어 로 새 로 
운 쏘프트웨어 를 개 발하라는 압력 을 받고 있 다. 이 때 발생하는 문제 는 다음과 같다. 적 당 
한 객체지향언어는 무엇인가? 20년전에는 사실상 단 하나의 선택 즉 Smalltalk 만이 가능 
하였다. 그러 나 현재 대 다수의 객체지향쏘프트웨어들은 C++ 로 작성되고 있다. 여기 에는 
여 러 가지 리유가 있 다. 그 하나는 C++ 콤파일 러 의 광범한 응용성 이 다. 사실 C++ 콤파일 러 
는 원천코드로부터 C 에로 단순히 번역하며 그다음 C 콤파일러를 호출한다. 그렇기때문에 
C 콤파일러를 가지고 있는 임의의 콤퓨터는 본질상 C++ 를 다룰수 있다. 

그러나 C++ 가 대중화되고 있는 실제적인 원인은 그것이 C 와 외적인 류사성이 있기 
때 문이 다. 유감스럽 게 도 많은 경 영 자들은 C++ 를 단순히 C 의 상위모임 으로서 간주하며 
따라서 C 를 알고 있는 임의의 프로그람작성자가 추가적인 부분들을 신속히 찾아 낼수 
있 다고 결론 짓는다. 실지 로 문법 적 인 견지 에 서 C++ 는 본질상 C 의 상위모임 이 다. 그러 나 
개념상 C++ 는 C 와 전혀 다르다. C 는 구조화파라다임의 제품이며 반면에 C++ 는 객체지 
향파라다임 을 위한 제 품이 다. C++ 를 리용하는것은 객체지향기법 이 리용되 며 제 품이 모둘 
이 아니 라 객체들파 클라스들로 조직되는 경우에만 합리적 이 다. 

그러므로 어떤 개 발기 업체 가 C++ 를 받아 들이 기 에 앞서 련관된 쏘프트웨어전문가 
들을 객체지향파라다임으로 숙련시키는것이 본질적이다. 제7장의 정보들을 가르쳐 주 
는것 이 특별히 중요하다. 객체지향파라다임 이 쏘프트웨어 를 개 발하는 다른 방법 이며 
명백한 차이 가 무엇 인가를 모든 성 원들 특히 관리 자측에 명백하지 않는 한에서는 C 가 
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아니 라 C ++ 로 작성 된 코드이지 만 구조화파라다임 이 계 속 리용되 게 될 것 이 다. 개 발기 
업체가 C 로부터 C ++ 로 전환한 결과에 실망하게 되는 경우에 한가지 중요한 인자는 
객체지향파라다임 에 대 한 교육을 받지 못한것 이 다. 가령 어떤 개 발기 업체 가 Java 를 받 
아 들이 기 로 결심 하였 다고 하자. 이 경우에 구조화파라다임 으로부터 객체지향파라다임 
에 로 점 차적 으로 이 행하는것은 불가능하다. Java 는 순수한 객체지향프로그람작성언어 
이며 구조화파라다임의 기능들과 절차들은 지원하지 않는다. C ++ 와 같은 혼성객체지 
향언어 와는 달리 Java 프로그람작성 자들은 처 음부터 객체지 향파라다임(오직 객체지 향파 
라다임 만)을 리용하여 야 한다. 하나의 파라다임 으로부터 다른 파라다임 에 로 급격 히 이 
행하여 야 할 필요성 으로부터 개 발과정 이 C ++ 나 00- C 0 B 0 L 과 같은 혼성객 체지향언어 
에 로 전환하려 고 할 때보다 Java (또는 Smalltalk 와 같은 순수한 객 체지향언어)를 받아 
들이 려 하는 경 우 교육과 숙련은 한층 더 중요한 문제 로 나선다. 4세 대언어 로 실현하 
면 어떤가? 이 론의는 다음절에서 진행된다. 

1 4. 2. 4세대언어 

최초의 콤퓨터들은 해석기도 콤파일러도 없었다. 이 를퓨터들은 배선판으로 장치화 
하거 나 스위 치 를 설정하는것 으로서 2진코드로 프로그람작성되 였 다. 이 와 같은 2진기계코 
드가 1세 대언어 였 다. 2세 대언어 들은 1940년대 말과 1950년대 초에 개 발된 아쌤 블리 어들이 
다. 프로그람들을 2진코드로 작성하는것 대 신에 명 령 들은 

mov $17, next 

와 같은 기 호적인 표식으로 표현되 였다. 일반적으로 매 개 아쌤 블리 어명 령들은 하나의 기 
계코드명 령 으로 번역 된다. 그러 므로 비 록 아쌤 블리 어가 기 계코드보다 작성 하기 쉽 고 유 
지정비 를 진행하는 프로그람작성 자가 리해 하기 쉽 다고 하여 도 아쌤 블리 어원천코드는 기 
계코드와 같은 길이를 가지였다. 

C , C ++, Pascal 또는 Java 와 같은 3세 대언어(또는 고급언어)의 리면에 있는 착상은 고 
급언어의 한개 명령문이 5 또는 10개의 기계코드명령으로 번역된다는것이다(이것은 또 
하나의 추상화실 례 이 다. 7.4.1 을 보시 오.). 결 국 고급언 어코드는 그와 등가인 아쌤 블리 어 
코드보다 상당히 짧다. 고급언 어코드는 또한 리해 하기 쉬 우며 그로부터 아쎔 블리 어코드 
보다 유지정 비 하기 가 쉽다. 고급언 어 들은 그와 등가적 인 아쎔 블리 어코드만큼 그렇 게 효 
률적이 아닐수도 있지만 이것은 유지정비에서의 편리성에 비해 볼 때 큰 문제가 아니다. 
이 러한 개념은 1970년대 말에 더욱 확인되였다. 4세대 언어 (4 GL ) 설계의 한가지 중요한 목 
적은 매개의 4 GL 명령문이 30 지어는 50개의 기계코드명령과 등가로 되게 하는것이다. 
Focus 또는 Natural 과 같은 4 GL 로 작성된 제품들은 원천길이가 보다 짧으며 때문에 개발 
이 보다 빠르고 유지 정 비 하기 도 더 쉽다. 

기 계코드로 프로그람을 작성하는것 은 어 렵 다. 아쎔 블리어 로 프로그람을 작성하는것 
은 약간 더 쉬 우며 고급언 어 를 리용하는것 은 훨 씬 더 쉽다. 4 GL 의 두번째 로 중요한 설 
계 목적 은 프로그람작성 에서의 편리 성 이다. 특히 대 부분의 4 GL 들은 비 절 차적이 다(이 것 
을 명백히 하려면 다음의 《알고 싶은 문제》를 보시오.). 실례로 그림 14-1 에 보여 준 


452 



명령을 고찰하자. 이 비절차적명령을 절차적으로 실행될수 있는 기계코드명령렬로서 번 
역 하는것 은 4 GL 콤파일 러 의 책 임 이 다. 


알고 싶© @제 

몇년전에 나는 뉴욕의 그랜드4트럴 (Grand Central ) 역전밖에서 택시를 불러 세- •고 운 
전수에게 《링컨센터로 갑시다.》라고 말하였다. 이것은 하나의 비절차적요구이다. 버냐하 
면 내가 희망하는 결과를 말하였지만 그 결과를 어떻게 달성하겠는가 하는 결심ᄀ • 운전 
수에게 맡겼기때문이다. 나는 그 운전수가 이 나라에서 사는지 2개월도 안되는 중 난유럽 
에 서 온 이 민자이 며 사실 이 도시 를 전혀 모르고 있 다는것 을 알게 되 였 다. 그리하< 나는 
재빨리 비절차적요구를 다음과 같은 절차적요구로 바꾸었다. 

《곧추, 곧추 갑시다. 다음번 신호등에서 오른쪽으로 꺾으시오. 오른쪽입니다. 2■른쪽 
바로 여기서，예, 오른쪽입니다. 이제는 곧추 갑시다. 천천히 갑시다. 천천히!》이* 게 링 
컨센터에 도착할 때까지 계속 하였다. 


for every surveyor 
if rating is excellent 
add 6500 to salary 

그림 14-1. 비 절차적인 4 세대언어 

4 GL 으로 전환한 개 발기 업 체 들이 성 공한 실례 는 많다. 이 전에 COBOL 을 리용한 몇개 
의 개 발기 업 체 들은 4 GL 을 리 용함으로써 실 지 로 생 산성 을 10 배 늘이 였 다고 보고하였 다. 
많은 개 발기 업 체 들이 4 GL 을 리용함으로써 생 산성 이 실지 로 증가하였 다는것 을 발견하였 
지만 그렇게 극적인것은 아니다. 다른 기업체들은 4 GL 을 시도하였으나 그 결과에 크게 
실망하였다. 

이와 같은 불일치 원인은 하나의 4 GL 이 모든 제품들에 적당한것 같지 않다는것이다. 
반대 로 특정한 제품에 대 하여 정 확한 4 GL 을 선택하는것 이 중요하다. 실례 로 Playtex 회 
사는 IBM 의 응용개 발프로그람(서쌍// caton Development Facility ; ADF ) 을 리 용하고 COBOL 
보다 80 대 1 의 생산성증대를 보고하였다. 

이 런 뚜렷 한 결과에 도 불구하고 Playtex 는 그이후에 도 관리 자측이 응용프로그람개 발 
기 능 ( ADF ) 에 덜 적 합하다고 생 각하는 제 품들에 COBOL 을 리용하였 다 [ Martin , 1985]. 

이러한 불일치에 대한 또 하나의 리유는 대부분의 4 GL 들이 강력한 CASE 작업대들과 
환경들로 지원되고 있다는것 이다 (5.5). 

CASE 작업대들과 환경들은 장점과 약점을 모두 가질수 있다. 2.11 에서 설명한바와 같 
이 낮은 성숙단계 에 있는 개 발기 업체 에서는 대 규모 CASE 를 도입하지 않는것 이 더 좋다. 
그 원 인은 CASE 작업 대 나 환경 의 목적 이 쏘프트웨 어개 발공정 을 지 원하는것 이 기 때 문이 다. 
1준위에 있는 개발기업체는 쏘프트웨어개발공정을 가지지 못한다. 만일 이 시점에서 
CASE 가 어 떤 4 GL 에 로 이 행 하기 위한 수단으로써 도입된다면 이것은 임의 의 공정 에 준 
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비 되 여 있지 않는 개 발기 업체에 어떤 공정 을 떠 맡기 게 될 것 이 다. 그 결말은 일 반적 으로 
불만족스러우며 또 비 참하게 될 수 있다. 사실 이 미 보고된 많은 4 GL 실패 들은 4 GL 그자 
체가 아니라 련관된 CASE 환경의 영향에 기인될수 있다. 

4 GL 에 대 한 43개 개 발기 업 체 들의 립장에 대 하여 문헌 [ Guimaraes , 1985] 에 서 보고되 
였다. 4 GL 의 리용은 사용자가 개 발기 업 체의 자료기 지 에서 추출한 정 보들을 요구할 때 
자료처리부서가 보다 신속히 응답할수 있게 하기때문에 사용자오유를 줄인다. 그러나 여 
기에는 여러가지 문제점들도 있다. 일부 4 GL 들은 오랜 응답시간으로 하여 느리고 효과 
적 이 아니 라는것 이 증명 되 였 다. 하나의 제 품은 기 껏하여 12명 의 협 동하는 사용자들을 지 
원 하면서 IBM 4331주콤퓨터상에 서 CPU 주기 의 60%를 소비하였 다. 전체 적 으로 4 GL 을 3 
년동안 리용한 28개 의 개 발기 업 체 들이 리 득이 비 용을 릉가하였 다는것 을 인식하였 다. 

어느 한 4 GL 도 쏘 프트웨 어시장을 독점하지 못하고 있다. 반면에 수백여개의 4 GL 이 
존재하고 있다. DB 2, Oracle , PowerBuilder 을 비롯한 일부 언어들이 상당한 규모의 사용자 
그룹을 형 성 하고 있 다. 4 GL 의 광범한 증대 는 4 GL 을 정 확히 선택할 때 심 중한 주의 를 돌 
려야 한다는것을 말해 주고 있다. 물론 몇개의 개발기업체들은 하나이상의 4 GL 을 지원 
할수 있는 여 유가 있다. 일 단 하나의 4 GL 이 선택되 여 리용되 면 개 발기 업체 는 련이은 제 
품들에 대 하여 그 4 GL 을 리용하든가 4 GL 을 도입 하기전에 리용한 언어 에 의 거하든가 하 
여 야 한다. 

생 산성 에 서 잠재 적 인 리득이 있음에 도 불구하고 4 GL 을 잘못 리용할 때 에 잠재 적 인 
위험성 이 존재한다. 많은 개 발기 업체들은 현재 개 발하는 제품들에 대한 큰 예 비를 가지 
고 있으며 또 수행해야 할 유지정비와 관련한 많은 과제들을 가지고 있다. 대다수의 
4 GL 의 설 계 목적 은 말단사용자프로그람작성 jwogrammhg ) 즉 그 제 품을 리 용할 

사람들이 프로그람을 작성하게 하는것 이 다. 실례 로 4 GL 이 출현하기전에 보험회 사의 투 
자관리 자는 자료처 리 관리 자에 게 채 권명세 표를 고려하여 어 떤 정 보를 현시하여 주는 제 품 
을 요청 하였을것 이 다. 그다음 투자경 영 자는 1년동안 기 다리든가 자료처 리그롭이 시 간을 
얻어내여 그 제품을 개발하도록 할것이다. 4 GL 은 이전에 프로그람작성을 해보지 않은 
투자경 영 자가 남의 도움을 받지 않고 희 망하는 제 품을 작성할수 있 을만큼 그렇 게 단순하 
게 리 용할수 있을것 을 기 대하였 다. 말단사용자프로그람작성 은 전문가들에 게 현존하는 제 품 
들에 대 한 유지정 비를 맡기고 제품개 발에 대 한 재고량을 줄이는것을 도울 작정이 였다. 

실천적으로 말단사용자프로그람작성은 위험을 동반할수 있다. 먼저 모든 제품개발이 
전문가들에 의하여 수행 되 는 정 황을 고찰하자. 콤퓨터 전문가들은 콤퓨터의 출력 을 믿지 
않는데 습관되여 있다. 결국 제품개발기간에는 모든 출력의 1%미만이 정확할수 있다. 한 
편 제품에 오유가 없을 때까지는 그 어떤 제품도 사용자에게 배포되지 말아야 하기때문 
에 사용자는 모든 콤퓨터출력 을 믿게 되 여 있다. 이제 는 말단 사용자프로그람작성 이 장 
려되는 정황을 고찰하자. 프로그람작성에 경험이 없는 사용자가 사용하기 쉬운 비절차적 
4세 대언어 로 코드를 작성할 때 사용자가 출력 을 믿는것 이 자연스러 운 경 향이 다. 결국 몇 
해동안 그 사용자는 콤퓨터의 출력을 믿도록 명령 받아 왔다. 결과 많은 업무결정들은 매 
우 부정 확한 말단사용자코드로 생성된 자료에 의거하여 왔다. 일부 경우에 어 떤 4 GL 의 
사용자친절성 은 재 정 적 인 파산을 초래 하였다. 

또 한가지 잠재적인 위험요소는 일부 개발기업체들에서 사용자들이 개발기업체의 자 
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료기 지 를 갱 신하는 4GL 제 품들을 작성하도록 하려 는 경 향이 다. 사용자에 의하여 생 겨 난 
프로그람작성오유는 종국적으로 전체 자료기지의 와전을 초래할수 있다. 경험은 명백하 
다. 경험이 없거나 숙련되지 못한 사용자들이 프로그람을 작성하는것은 비록 극히 치명 
적 이 아니 라고 해도 회사에 재정적손해를 끼치게 될것 이 다. 4GL 의 최종선택은 관리 자측 
이 하게 된다. 

이러한 결심을 할 때 관리자측은 4GL 리용에서의 많은 성공실례들은 참고하여야 한 
다. 동시 에 관리 자측은 부적 당한 4GL 의 리용， CASE 환경 의 신속도입 또는 개 발공정 의 불 
충분한 경 영 으로 인하여 초래된 실태 들을 세밀히 분석하여 야 한다. 실례 로 실패 의 공통 
적 인 원인은 관계 자료기지 리 론 [Date, 1999] 을 비롯하여 4GL 의 모든 측면들에 대 하여 개 
발림 이 철저 히 파악하는것 을 무시 하고 있는것 이 다. 경 영 자는 특정한 응용령 역에서의 성 
공과 실패를 모두 연구하고 과거의 오유로부터 교훈을 찾아야 한다. 정확한 4GL 을 선택 
하는것 은 커 다란 성 공과 비 참한 실패 의 갈림 길을 의 미할수 있 다. 

실현언어를 결정하였기때문에 다음의 론점은 쏘프트웨어공학의 원리들이 어떻게 
보다 품질이 좋은 코드작성에로 이끌어 갈수 있겠는가 하는 문제이다. 

14.3. 를■한 프로그람작성실천 

훌륭한 코드작성품격과 관련한 대부분의 권고들은 특정한 언어에 국한되여 있다. 실 
례 를 들면 COBOL88 준위 입 력 또는 Lisp 에 서 의 괄호의 리 용과 관련 한 제 안들은 Java 로 제 
품을 실현하는 프로그람작성자들에게는 그리 흥미가 없다. 실현에 열중하고 있는 독자들 
에 게 는 헨 리 레 가드 (Henry Ledgard) 가 쓴 책 과 같은 여 러 책 들중에 서 어 느 하나를 읽 을 
것이 요구되는데 그러한 책들에서는 그 제품이 실현되고 있는 특정한 언어에서의 홀륭한 
프로그람작성 습관들에 대 하여 설명하여 준다. 아래 에서 언어 에 의 존하지 않는 훌륭한 프 
로그람작성습관에 관하여 몇가지 권고한다. 

일관하고 의미 있는 변수이■의 리용 제1장에 서 서 술한것 처 럼 쏘프트웨 어운영 비 의 
평균 3 분의 2 는 유지정비에 돌려 지고 있다. 이것은 어떤 모둘을 개발하고 있는 프로그 
람작성 자는 그 모둘에 서 작업하는 많은 사람들가운데 서 첫 사람에 지 나지 않는다는것 을 
의미한다. 어떤 프로그람작성 자에게 있어서 변수들에 자기 에게만 의미 가 있는 이름을 주 
는것은 비생산적이다. 여기서 쏘프트웨어공학의 범위내에서 용어 《의미 있는》은 《유 
지 정 비를 진행 하는 미 래 의 프로그람작성 자의 견지 에 서 《 의 미 있는》을 의 미 하고 있다. 
다음의 《 알고 싶은 문제》에서 이 점 에 대 하여 설명한다. 

의미 있는 변수이름을 리용하는것외에 변수이름들이 일치하는것이 마찬가지로 중요 
하다. 실례로 하나의 모둘안에서 다음의 4 개 변수 즉 averageFreq, frequencyMaximum, 
minFr, frqncyTotl 이 선언되 였 다고 하자. 코드를 리 해 하려 고 하는 유지 정 비 프로그람작성 자 
는 freq, frequency, fr, frqncy 가 모두 같은것 과 관계 되 여 있는가를 알아야 한다. 만일 같은 
것 과 관계 되 여 있 다면 식 별 단어 가 리 용되 여 야 한다. 비 록 freq 또는 frqncy 는 부분적 으로 
마음에 들지 만 fr 는 마음에 들지 않으므로 오히 려 frequency 를 리 용한다. 그러 나 만일 하 
나 또는 그이상의 변수이름들이 다른 량과 관련되여 있다면 rate 와 같이 전혀 다른 이름 
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이 리용되여야 한다. 거꾸로 동일한 개념을 지적하기 위하여 두개의 각이한 이름을 리용 
하지 말아야 한다. 실례로 average 와 mean 은 모두 같은 프로그람내에서 리용되지 말아야 
한다. 


알:2 싶 e @제 

1970년대 말에 남아프리가의 요한네스부르그에용 f •개의 림 으로 구성된 하나』 작은 
쏘프트웨어개발기업체가 있었다. 림 A 는 모잠비크에서 온 이주민들로 구성되였는 t 그들 
은 뽀르뚜갈래생이였고 모국어# •_ 뽀르뚜갈어였다. 그들이 작성하는 코드는 훌륭 1•였다. 
변수이름들은 의미가 있었지만 유감스럽 게도 뽀르뚜갈어로 말하는 사람들에게만 1러하 
였 다. 림 B 는 모국어 가 헤 브라이어 인 이스라엘 이 주민들로 조직 되 였 다. 그들이 직 영 하는 
코드도 훌륭하였고 변수이름들도 의미가 있었지만 헤브라이어로 말하는 사람에게 1 ■ 그러 
하였다. 

어느 날림 A 가 림책임자와 함께 집단적으로 사직하였다. 림 B 는 림 A 가 작ᅮ 한 코 
드의 어 느 하나도 전혀 유지 정 비할수 없 었 다. 왜 냐하면 그들은 뽀르뚜갈어 로 말하; 못하 
였기때문이다. 1르두갈어로 말하는 사람인 경우에만 의미가 있는 변수이름들은 헤 으라이 
어와 영어로 말할수 있는 이스라엘인들에게는 리해될수 없었다. 쏘프트웨어개발기< 체 책 
임자는 림 A 를 대신할 또르두갈어로 말할수 있는 프로그람작성자들을 충분히 3 .할수 
없었고 회4픗 자기들의 원천코드를 마는 유지정비할수 없게 된것으로 하여 불만- ■ 품은 
손님들의 법적배상압력을 받고 곧 파산되게 되였다. 

이 정 황은 일찌 기 피할수 있는것 이 였 다. 회 사사장은 시 작부터 모든 변수이 름ᅮ 모든 
남아프리카 콤퓨터전문가들이 리해할수 있는 언어인 영어로 작성하도록 요구했어< : 하였 
다. 그러면 변수이름들은 유지정비를 진행하는 모든 프로그람작성자들에게 의미가 U 었을 
것 이 였다. 


일치성의 두번째 측면은 변수이름에서 요소들의 순서이다. 실례로 만일 한 변수가 
frequencyMaximum 으로 이름 지 어 졌다면 minimumFrequency 라는 이름은 혼동될 것 이 다. 그것 
은 FrequencyMinimum 으로 이름 지 어 져 야 한다. 앞으로의 유지정 비 프로그람작성 자에게 코드 
가 명백 하고 애매성 이 없도록 하기 위하여 앞에서 렬거 한 4 개 의 변수들은 각각 다음과 같 
이 이 름 지 어 야 한다. 즉 frequencyAverage , 仕 equencyMaximum ^ irequencyMinimum , frequencyTotal 
이다. 이 대신에 요소 frequency 를 4 개의 변수이름의 끝에 오게 할수도 있다. 즉 변수이름 
은 averageFrequency , maximumFrequency , minimumFrequency , totalFrequency 로 할 수 있 다. 
이 두 변수이름모임중에서 어느것을 선택하는가는 문제가 아니다. 중요한것은 우의 어느 
한 모임 에 서 모든 이 름들을 선택하는것 이 다. 

코드를 보다 쉽게 리해할수 있게 하는 여러가지 서로 다른 이름짓기습관들이 제시되 
였다. 그 착상은 어떤 변수의 이 름에 류형정 보를 병 합하는것 이 다. 실례 로 들면 ptrChTmp 
는 어 떤 문자 ( Ch ) 에 대 한 지 적 자형 ( ptr ) 림 시변수 ( Tmp ) 를 의 미 하고 있다. 이 와 같은 가장 
널 리 알려 진 이 름짓 기방법 은 마쟈르식이 름짓 기 습관이 다 [ Klunder , 1988] (만일 왜 마쟈르식 
이라고 부르는가를 알고 싶다면 다음의 《알고 싶은 문제》를 보시오.). 이러한 여러가지 
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방법들이 가지고 있는 한가지 결함은 대방이 변수이름들을 발음할수 없을 때 코드검토의 
효과성 (14.9) 이 감소될 수 있 다는것 이 다. 변수이 름들을 한글자씩 발음하여 야 하는것 은 매 
우 시끄러운 일이다. 


알:2 싶 e ©제 

용어 마쟈르식 이 름짓 기 습관 (/ ftmgan'aw Naming Conventions )^ 대 하여 서 는 두가; 로 설 
명 할수 있다. 첫째 는 이 습관이 마자르에 서 출생 한 찰스 시모니 (Charles Simonyi )^ .의■해 
발명되였다는것이다. 둘째는 일반적으로 인정되고 있는것인데 초학도에게 있어서 이 습 
관에 따르寒 변수이름들로써 프로그람을 작성하는것은 마쟈르어처럼 읽기가 쉽 다는것 
이다. 그러나 이 습관을 리용하는 기업체(마이크로쏘프트와 같은)들은 이 습관。마쟈 
호식이 름짓기관습에 경험 이 있는 사람들에 게서 코드가독성을 중가시 킨다는것을 는장하 
고 있다. 


자기식으로 문서화한 쿄드작성문제 프로그람작성 자들에 게 도대 체 무엇 때 문에 그들 
이 작성한 코드에 아무런 설명 문도 없는가고 물으면 프로그람작성 자는 자주《 나는 자기 
식으로 문서화한 코드를 작성한다.》고 자랑스럽게 답변한다. 이것은 그들이 리용하는 변 
수이 름들이 아주 주의 깊게 선택 되 고 그들이 작성한 코드들이 그 어 떤 설명 문도 필요 없 
을 정 도로 섬 세하게 작성 된 다는것 을 의 미한다. 자기 식 으로 문서 화한 코드는 존재 하기 는 
하지만 극히 드물다. 그대신 일반적으로 쓰이는 방법은 모둘이 작성될 때 프로그람작성 
자가 코드에 서의 모든 미 묘한 차이 를 판별하는것 이 다. 프로그람작성 자가 매 모둘에 같은 
형식을 리용한다면 5년내 에서는 코드들이 원래의 프로그람작성 자의 모든 측면에서 여전 
히 명 백할것 이 라는것 은 상상할수 있 는 일 이 다. 

유감스럽게 도 이것은 잘못된 상상이 다. 중요한 문제는 쏘프트웨 어품질보증그롭으로 
부터 시 작하여 수많은 유지정 비프로그람작성 자들에 이 르기 까지 그 코드를 읽는 다른 모 
든 프로그람작성 자들에게 모둘이 쉽 게 명 백하게 리해될수 있는가 하는것 이 다. 문제는 경 
험 이 없는 프로 그람작성 자들에 게 유지 정 비 과업 을 맡기 고 그들을 철 저 히 관리 하지 않는 
잘못된 실천경우가 있게 되는것과 관련하여 더욱 심각하게 제기된다. 모둘들에 대한 문 
서 화 되 지 못한 코드는 경 험 있는 프로 그람작성 자에게 도 부분적 으로만 리해 될수 있 다. 더 
욱 한심한 경우는 유지정비 프로 그람작성자가 경험이 없을 때이다. 

있을수 있는 문제 들의 종류를 보기 위하여 변수 xCoordinateOffositionOfRobotArm 을 
고찰하자. 이 와 같은 변수이 름은 의 심할바없 이 단어의 모든 의미 에서 자기 식의 문서화를 
실현하고 있지 만 많은 프로그람작성 자들은 31개 문자로 된 변수이 름을 리용하려 하지 않 
으며 특히 그 변수가 자주 리용된 다면 더 욱 그러하다. 그대 신 보다 짧은 이 름 례하면 
xCoord 를 리용한다. 그 리 면에 있는 원 인은 만일 총적 인 모둘이 로보트팔의 움직 임 을 처 
리한다면 xCoord 는 그 로보트팔위 치 의 X 자리표와만 련관될 수 있 다는것 이 다. 비 록 이 변 
수는 개발공정의 범위내에서는 리치에 맞지만 유지정비를 위하여서는 필수적으로 옳은것 
이 아니다. 
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유지 정 비 프로그람작성 자에 게 전반적 제품에 대 한 충분한 지식 이 없어서 이 모둘내 에 
서 xCoord 는 로보트의 팔과 관련된다는것 을 리해할수 없을수도 있고 그 모둘의 작업 을 
리해하는데 필요한 문서가 없을수도 없다. 이러한 종류의 문제를 극복하기 위한 한가지 
방법은 매 변수의 이름을 프로그람의 서두 즉 서두설명문 ( pra/ogwe cowmen / s ) 에서 설명 하 
도록 요구하는것 이 다. 만일 이 규칙 을 따르게 된 다면 유지정 비프로그람작성 자는 변수 
xCoord 가 로보트팔위 치 의 x 자리표를 위하여 리용된 다는것 을 인 차 리해하게 될 것 이 다. 

서두설명문은 매개의 단독 모둘들에서 필수적인것이며 매 모둘의 시작에서 제공되여 
야 한다. 최소한의 정보는 다음과 같다. 즉 모둘의 이름，모둘의 사명 에 대 한 간단한 설 
명，프로그람작성자의 이름，모둘이 작성된 날자，모둘이 허가된 날자，모둘의 인수들，자 
모순으로 정 렬된 변수목록, 모둘이 호출하는 파일 이 름, 이 모둘에 의하여 변경 되 는 파일 
들의 이름，오유처 리능력, 이 후의 회귀시 험를 위해 리용되는 시 험자료를 포함하고 있는 
파일 이 름，변경 목록, 변경 의 날자와 변경 자，알려 진 오유들이다. 

비록 어떤 모둘이 명백하게 작성된다고 하여도 그 모둘의 사명과 그것 이 어떻게 실 
현되는가를 리해하기 위하여 매개 행을 읽어야 한다면 그것은 타당치 않다. 서두설명문 
은 다른 사람들이 중요한 점 들을 쉽 게 리해할수 있 게 한다. SQA 그룹성 원 또는 어 떤 특 
정한 모둘을 변경하는 유지정 비전문가들만이 그 모둘의 매행을 읽 게 하여 야 한다. 

서 두설 명 문외 에 직 접 삽입 설 명 문 (inline comment ) 을 코드에 삽입 하여 유지 정 비 전문가들 
이 그 코드를 리해하는것 을 도울수 있게 하여 야 한다. 코드가 명 확치 않은 방식 으로 작 
성 되 거 나 해 당 언 어 의 아주 리 해 하기 힘 든 측면들을 리 용하는 경 우에 만 직 접 삽입 설 명 문 
을 리용하여야 한다. 반대로 혼돈을 일으키는 코드들은 어떤 보다 명백한 방법으로 작성 
되 여 야 한다. 직 접 삽입 설명 문은 유지 정 비 프로그람작성 자들을 돕기 위 한 수단이 며 불충분 
한 프로그람작성실천을 추동하거 나 변명하는데 리용하여서 는 안된다. 

파라에터들의 리용 절대상수 즉 값이 절대로 변하지 않는 변수들은 매우 적다. 실례 
로 위성사진들은 하와이의 펄 하버 (Pearl Harbor ) 의 위도와 경도를 병 합하고 있는 해 저항 
해체계 에서 변경되 여 펄 하버의 정 확한 위 치에 관하여 보다 정 확한 기하학적자료들을 반 
영 하도록 되 여 있다. 또 다른 실례 를 들어 보면 판매세 는 절대 상수가 아니 다. 립 법자들은 
시시각각 판매세를 변경시키려고 시도한다. 가령 판매세률이 현재 6.0%라고 하자. 만일 
값 6.0 이 어 떤 제 품의 여 러 가지 모둘안에 고정 되 여 있 다면 그 제 품을 변경 시키 는것 은 하 
나의 기본과제로 된다. 이때 《상수》 6.0 의 하나 또는 두개 실례의 가능한 결과를 무시 
하고 어떤 상관 없는 6.0 을 실수로 변경시키게 된다. 

한가지 좋은 해결대책은 다음과 같은 C ++ 선언 


const float salesTaxRate = 6.0; 


이 나 Java 선 언 


public static final float salesTaxRate = (float) 6.0; 

을 리용하는것 이 다. 그러 면 판매 세률값이 요구될 때 마다 상수 salesTaxRate 가 리용되 고 
수 6.0 은 리용되 지 않게 된 다. 만일 판매세률이 변화된 다면 salesTaxRate 의 값을 포함하 
고 있는 행만 편집기로 변경시키면 된다. 더 좋기는 판매세의 값은 실행서두에서 어떤 
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파라메 터파일로부터 읽어 들여 야 한다. 이와 같은 피상적 인 상수들은 파라메 터로서 취급 
되여야 한다. 이렇게 되면 만일 어떤 값이 임의의 원인으로 하여 변경되여야 한다면 이 
변경들은 신속히，효과적으로 실현될수 있다. 

가독성을 증대시키기 위한 쿄드배치 어떤 모둘을 읽 기 쉽게 하는것은 비 교적 간단하 
다. 실례로 비록 대부분의 프로그람작성언어들에서 한 렬에 한개이상의 명령문들을 쓸수 
있다고 하여도 한 행에 한개 이상 명 령문을 쓰지 않는 방법 이 다. 아마도 들여쓰기 방법은 
가독성을 증대시키기 위한 가장 중요한 기법으로 될것 갈다. 만일 들여쓰기를 리용하여 
코드를 리해 하기 쉽 게 하지 않았더 라면 제7장의 코드실 례 들은 얼 마나 리해 하기 어 렵겠는 
가를 상상해 보라. C ++ 또는 Java 에서 들여쓰기는 대응하는 {...} 쌍들을 련결시키는데 
리용될수 있다. 들여쓰기는 또한 어느 명령문들이 주어 진 블로크에 속하는가를 보여 준 
다. 사실 들여쓰기 는 인간적 존재 를 무시할수 있을 정 도로 매 우 중요하다. 그대 신 5.6 에 서 
서 술한바와 같이 CASE 도구들을 리 용하여 들여쓰기 가 정 확히 수행 된 다는것 을 확인하여 야 
한다. 

또 한가지 유용한 수단은 공백행 들이다. 모둘들은 공백행 들로 분리 되 여 야 한다. 공백 
행들로 큰 코드블로크들을 갈라 놓는것은 도움이 된다. 큰《흰 공백공간》은 코드를 보 
다 읽기 쉽고 리해하기 쉽게 한다. 

함유된 if 명령문 다음의 실례를 고찰하자. 그림 14-2 에 보여 준것처럼 어떤 지도가 
두개의 정 방형 으로 구성되 여 있다. 지 구면우의 어떤 점 이 지도정 방형 l(map square 1) 또 
는 지 도정 방형 2 (map square 2) 에 속하는가를 결 정 하기 위 한 코드를 작성 하는것 이 필 요 
하다. 그림 14-3 의 코드는 리해하기 어렵게 형식화되였다. 적당하게 형식화된 코드를 그 
림 14-4 에 제 시한다. 그럼 에 도 불구하고 if - if 와 if - else - if 구조들의 결 합이 너 무 복잡하여 
코드토막들의 정 확성 여부를 검 열하기 어 렵 다. 그림 14-5 에서는 이것 을 수정 하고 있다. 
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그림 14-2. 지도좌표 

if - if 구조를 포함하고 있는 복잡한 코드에 부닥칠 때 간단히 하기 위한 한가지 방법 은 
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if-if 결 합 


if < condition 1 > 
if < condition 2 > 

가 비록 <condition 1 〉이 성 립 하지 않는다고 해도 < condition 2 〉는 정의된다는 조건하 
에서 단독조건 


if < condition 1 > and < condition 2 > 
와 등가이라는 사실 을 리용하는것 이 다 . 


if (latitude>30 && longitude 〉 120) {if (latitude<=60 && longitude<=150) 
mapSquareNo= 1; else if (latitude<=90 && longitude<=150) mapSquareNo=2 
else print “Not on the map” ; } else print “Not on the map” ; 

그림 14-3. 잘못 형식화되여 있는 함유 if 명령 

if (latitude>30 && longitude 〉 120) 

{ 

if (latitude<=60 && longitude<=150) 
mapSquareNo= 1; 

else if (latitude<=90 && longitude<=150) 
mapSquareNo=2 

else print “Not on the map” ; 
else 

print “Not on the map” ; 

그림 14-4. 잘 형식화되였으나 잘못 구조화되여 있는 함유 if 명령 


if (longitude >120 && longitudex=150 && latitude>30 && latitude <=60) 
mapSquareNo= 1; 

else if (longitude >120 && longitude<= 150&& latitude>60 && latitude <=90) 
mapSquareNo=2 

else print “Not on the map” ; 

그림 14-5. 허용할수 있는 함유 if 명 령 

실례로 < condition 1〉은 어떤 지적자가 령이 아니라는것을 검사할수 있으며 만일에 
령 이 아니 라면 〈condition 2〉는 그 지 적 자를 리 용할수 있 다(이 문제 는 Java 나 C ++ 에 서 
는 발생하지 않는다. &&연산자는 만일 < condition 1〉이 실패하면 < condition 2〉가 평 
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가되지 않는다는것으로서 정의된다.). 

if - if 구조와 관련된 또 한가지 문제는 함유 if 명령문들이 너무 길어서 읽기 어려운 코 
드를 생성할수 있다는것 이 다. 경험적 인 규칙 으로서 3이상 깊이로 함유된 if 명 령문들은 좋 
지 못한 프로그람작성실례로서 피 하여 야 한다. 

14.4. 코드작성표준 

코드작성표준은 하나의 행 운으로 될 수도 있 고 하나의 재 앙으로 될 수도 있 다. 7.2 에 서 
는 일치적 인 응집도를 가진 모둘들은 일반적으로《매 모둘들은 35〜50개의 실행가능한 
명령문들로 구성될것 이 다.》와 갈은 규칙들의 결과로서 생성된다. 이와 갈은 독단적 인 방 
식 으로 규칙 을 서 술하는것 대 신에 다음과 갈은 형 식 화를 리용하는것 이 더 좋다.《 프로그 
람작성 자들은 35개보다 적 든가 50개보다 많은 실 행 가능한 명 령 문들을 가진 모둘들을 작 
성하기전에 관리자에게 물어 보아야 한다.》요점은 가능한 모든 정황에 응용될수 있는 
코드작성표준은 없 다는것 이 다. 

상부로부터 강요되 는 코드작성표준들은 무시 되 는 경 향이 있 다. 이 미 언급한바와 같 
이 한가지 쓸모 있는 경험 적규칙은 if 명 령 문이 3이 상 깊이 로 함유되지 말아야 한다는것 
이다. 만일 프로그람작성자들에게 if 명령문을 너무 깊이 함유하여 읽을수 없는 코드실례 
들을 제 시하여 준다면 프로그람작성 자들은 이 와 갈은 규칙 을 따를듯도 하다. 그러 나 아 
무런 론의 나 설명도 없이 강요되는 코드작성규칙들은 프로그람작성 자들이 지키지 않을수 
있 다. 더우기 이 와 같은 기 준들은 프로그람작성 자들과 경 영 자들사이 의 마찰을 초래하게 
될수도 있다. 더우기 어떤 코드작성표준은 기계로 검사될수 없는 한 그것은 SQA 그롭에 
게 있 어 서 많은 시 간을 랑비 하게 하든가 프로그람작성 자들과 SQA 그룹에 의하여 단순히 
무시되게 된다. 한편 다음과 같은 규칙을 고찰하자. 

•if 명령문의 함유는 개발림책임자의 사전동의가 없는 한 3개 깊이를 초과하지 말아 
야 한다. 

• 모둘들은 개 발림 책 임 자의 사전동의 가 없는 한 35〜50개 명 령 문들로 구성 되 여 야 한다. 

•goto 명령문의 리용은 피해야 한다. 그러나 개발림책임자의 사전동의가 있으면 앞 
방향 goto 명 령 문을 오유처 리 를 위 하여 리 용할수 있 다. 

이 와 같은 규칙 들은 기 준에 서 리랄시키 는 허 가와 관계 되 는 자료들을 포착하기 
위하여 어떤 기구가 설치된다는 조건하에서 기계적으로 검사될수 있다. 

코드작성표준의 목적은 유지정비를 보다 쉽게 하는것이다. 그러나 만일 어떤 기준 
이 쏘프트웨어개발자들의 생존을 어렵게 한다면 비록 프로젝트의 실현도중이라고 하여 
도 그 기 준을 변경하여 야 한다. 지 나치 게 제 한적 인 코드작성표준들은 비 생 산적 이 며 만 
일 프로그람작성 자들이 이 와 같은 틀안에 서 쏘프트웨어 를 개 발하여 야 한다면 쏘프트웨 
어생 산의 질 이 부득이 손해 를 입 게 된 다. 한편 if 명 령 문의 함유，모둘크기 , goto 명 령 문 
에 관하여 앞에서 렬거 한 기준들은 이 기준들로부터의 리랄에 관하여 결합한 어떤 기 
구와 함께 쏘프트웨어 의 질 을 개 선 할수 있 으며 결 국은 쏘프트웨 어공학의 기 본목적 을 
달성하게 된 다. 
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1 4. 5. 모듈의 재리용 

재 리용은 제8장에서 자세 히 서 술되 였 다. 사실 이 책 에서 는 재 리용에 관한 자료들을 
여 러 곳에 서 술하여 주었 다. 왜 냐하면 명세서 , 계 약서，계 획，설계모둘의 부분들을 비 롯 
하여 쏘프트웨 어개 발공정 의 모든 단계 들에 서 나오는 요소들이 재 리용되 기 때 문이 다. 이 것 
이 바로 재리용에 관한 재료들을 어떤 특정한 단계에서가 아니라 이 책의 1편에 제시한 
리유이다. 비 록 모둘의 재 리용이 모둘들이 재 리용될 수 있 다는것 보다 훨 씬 일 반적 인 재 리 
용형 식 이 라고 할지 라도 이 장에 서 그것 을 강조하기 위하여 모둘의 재 리용에 대 한 자료를 
제 시하지 않는다는것 이 특별 히 중요하다. 

실현단계에서의 시 험 문제 를 다음에 고찰한다. 

1 4. 6. 모듈시험실례선택 

7장에서 설명한바와 같이 하나의 객체는 하나의 특정한 류형의 모둘이 다. 그러므로 이 
장에서 는 이 책의 나머지부분에서와 마찬가지 로 어떤 모둘에 대 하여 성 립하는것은 그 무 
엇 이 든지 일 반적 으로 객 체 들에 도 적 용한다. 그러 나 일부 론의 들은 객 체 들에 고유한것 이 다. 
이 절과 다음절들에서는 객체들에 고유한 시험과 관련한 문제들이 일반적인 모둘시험의 
범위내 에서 강조하여 론의된다. 

제 6.6 에서 지적한바와 같이 모둘들은 두가지 류형의 시험을 거 치게 된다. 즉 모둘의 
개 발기 간에 프로그람작성 자에 의하여 진행 되는 비형 식 적시 험과 프로그람작성 자가 모둘이 
정 확하게 기능하는것 같다고 만족한 이 후에 SQA 그룹에 의하여 진행되는 방법론적시험을 
거친다. 이 방법 론적시 험 에 대 하여서는 아래 에서 론의한다. 방법론적시험 에는 또 두가지 
기 본류형 이 있 다. 하나는 비실행 에 기 초한 시 험 인데 여 기서 는 모둘이 어떤 개발림 에 의하 
여 검 토된다. 다른 하나는 실행 에 기 초한 시 험 인데 여 기서 는 모둘이 시 험 실례 에 대 비하여 
실행된다. 이 러한 시험실례 들을 선택 하기 위한 기 법들을 이제 고찰하기로 하자. 

어떤 모둘을 시험하기 위한 최악의 방법은 우연시험자료를 리용하는것이다. 시험자 
는 건반앞에 앉아서 모둘이 입 력을 요구할 때마다 임의의 자료를 입 력한다. 앞으로 보게 
되겠지만 가능한 모든 시험실례들중의 극히 일부분을 시험할 시간도 없는데 이러한 시험 
실례 들은 쉽사리 ”_개이상에 도달할수 있다. 1,000개 되 나마나한 실행할수 있는 시험실 
례들을 우연적 으로 발생한 자료들에 랑비하기 는 너 무 아쉽다. 더 나쁜 경 우로서 콤퓨터 
가 입력을 요구할 때 갈은 자료에 대하여 한번이상 응답하는 경향도 있는데 이렇게 되면 
훨 씬 더 많은 시 험 실 례 들을 랑비 하는것 으로 될 것 이 다. 그러 므로 명 백 히 시 험 실 례 들은 체 
계적 으로 구성하여 야 한다. 

14. 6. 1 . 명세서시험과 쿄드시험 

어떤 모둘을 시험하기 위한 시험자료들은 두가지 기본방식으로서 체계적으로 구성될수 
있다. 첫번째 방법은 명세서 에 대하여 시험하는것 이 다. 이 기법을 검은통시험, 거동 
( behavioral)A ^ , 자료구동시 험，기 능시 험，입 출력 구동 (/ npM // ow 分) «/- 
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c / n ' v 대)시 험 라고도 부론다. 이 방법 에서 코드자체 는 무시 된다. 시 험실례 를 작성할 때 리 용 
하는 유일한 정보는 명세서이다. 다른 하나의 극단은 코드에 대한 시험인데 여기서는 시 
험 실례 들을 선택 할 때 명세 서 를 무시 한다. 이 방법 을 유리 통 ( g / aw -6 ox ) 시 험，흰통 ( w / n ’/ e - 
6 ox ) 시 험 , 구조적 On / cft / ra /) 시 험 , 론리 구동 (/ og / c - cWven ) 시 험, 경 로지 향 ( path - oriented ) 시 험 이 
라고도 부론다(이렇게 많은 서로 다른 용어들이 있게 되는 원인을 알려면 다음의 《알고 
싶은 문제〉〉를 보시 오.). 


알:2 싶 e ©제 

무엇때문에 갈은 시험개념에 이토록 많은 서로 다른 이름이 주어 지는가를 공 는것은 
응당하다. 쏘프트웨어공학에서 흔히 있는것처럼 같은 개념이 서로 다른 여러 연구 다들에 
의하여 독립적 으로 발견되 여 그 매 사람들이 자기 식의 용어 를 창안하게 된다. 쏘 뜨트웨 
어공학기업체가 이 단어들이 동일한 개념에 대한 서로 다른 이름이라는것을 깨달: :을 때 
는 이미 시간이 늦게 된다. /_서로 다른 이름들이 쏘프트웨어공학용어집에 이미 - •어 가 
있게 되는것이다. 

이 책 에서 는 용어 검은 ■시험 (Wac 灰-公 ox testing )^ 유리 ■시험 ( g / a & s - 公 ox testing ) 을 리용하 
고 있다. 이 용어들은 특수하게 서술된다. 우리 가 명세서를 시험할 때는 코드를 관전히 
불투명한 하나의 검은통으로써 취급한다. 거꾸로 코드를 시험할 때 에는 그 내부1 볼수 
있어야 한다. 때문에 용어 유리틍 시험을 리용하였다. 우리는 용어 힘틍 시험 (w rte-tojc 
testing )-%： 쓰지 않는다. 왜 냐하면 이것 이 약간 혼돈을 가져 오기때문이 다..義 하나」 흰색 
칠 을 한 통은 검 은색칠 을 한 통과 마찬가지 로 불투명한것 이 다. 


이제 명세서에 대한 시험으로부터 시작하여 이 두가지 기법들의 실행가능성에 대하 
여 고찰하자. 


1 4. 6. 2. 명세서시험의 실현가능성 

다음의 실례를 고찰하자. 어떤 자료처리제품에 대한 명세서가 5가지 류형의 대리권 
과 7가지 류형의 할인이 병합되여 야 한다는것을 서술하고 있다고 하자. 대 리권과 할인의 
가능한 모든 결 합을 시 험 하기 위 하여 서 는 35개 의 시 험실례 들이 필요하다. 대 리 권과 할인 
은 완전히 분리된 두개의 모둘로 계산되며 때문에 독립적으로 시험될수 있다는것을 말해 
야 소용이 없 다. 즉 검 은통시험 을 진행할 때 제 품은 하나의 검 은통으로 취 급되 며 그러므 
로 그것의 내부구조는 전혀 상관이 없다. 

이 실례는 각각 5개，7개의 서로 다른 값을 취하는 두개의 인자 대리권과 할인만을 
포함하고 있다. 임의의 현실적 인 제품들은 수백 가지 각이한 인자들을 가지게 된다. 가령 
20개의 인자만이 있고 그 매 인자는 4개의 서로 다른 값만을 취할수 있다고 하여도 총 
4 20 또는 1.1 X 10 12 개 의 서 로 다른 시 험실례 들을 고찰하여 야 한다. 

1조개 이상의 시험실례 가 내재 하고 있는 의 미를 고찰하기 위하여 그것들을 모두 시 험 
하는데 얼마나 오랜 시간이 걸리는가를 고찰하여 보자. 만일 어떤 프로그람작성자림이 
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k 1 개의 속도로 시험실례들을 발생, 실행, 조사한다고 하 
100만년이상 걸리게 될것이다. 

L 로 명세서 를 빠짐 없 이 시 험하는것 은 조합폭발로 인하 o 
a 실례가 너무 많아서 고찰할수 없는것이다. 다음으로 코 


14. 6. 3. 쿄드시험의 실현가능성 

일반적인 형식의 코드시험에서는 모둘을 통하는 매 경로 
하고 있다. 이것이 실현불가능하다는것을 보기 위하여 : 
찰하자. 이 흐름도가 아주 평범한것 같아도 거기에는 ] 
다. 흐름도의 중심에 있는 6개의 그늘진 통그룹을 통과균 
부터 흐름도를 통과하는 가능한 경로의 총 개수는 다음: 






하나의 단독순환을 포함하고 있는 간단한 흐름도를 통하는 경로가 이렇게 많을수 
있을진데 적당한 크기와 복잡도를 가지며 여러개의 순환을 가지는 어떤 모둘에서 서 
로 다른 경로의 총 개수가 얼마나 많겠는가를 어렵지 않게 상상할수 있다. 간단히 말 
하여 방대한 수량의 경로개수는 명세서에 대한 철저한 시험과 마찬가지로 코드에 대 
한 철저한 시험도 실현불가능하게 만든다. 

코드시험이 문제시되는 추가적인 리유들도 있다. 코드에 대한 시험은 시험자가 매 
경로를 시험해 볼것을 요구한다. 제품안의 모든 오유를 발견해 내지 않고 매 경로를 시 
험하는것이 가능할수도 있다. 즉 코드에 대한 시험은 믿을수 없다. 이것을 보기 위하여 
그림 14-7 에 보여 준 코드토막을 고찰하자 [ Myers , 1976]. 이 토막은 3개의 옹근수 x , y , z 
의 등가성 을 시 험 하기 위하여 작성하였는데 여 기서는 만일 3개 수의 평 균값이 첫번째 수 
와 같다면 그 3개 수자는 등가이라고 하는 완전히 그릇된 가정 을 리용하고 있다. 두개 의 
시 험실례 를 그림 14-7 에 보여 준다. 첫 번째 시 험실례 에서 3개 수의 평 균값은 6/3 또는 

if (( x + y + z )/3) = x ) 

print “ x ， y，z 는 값이 다 갈다. ” ; 

else 

print “ x ， y，z 는 다 같지 않다. ” ; 

시험자료 1 : x = 1 ， y = 2, z = 3 

시 험자료 2 : x = y = z = 2 

그림 14-7. 두 시 험자료를 통하여 3개 의 옹근수가 다 

같은가를 결정하는 부정확한 코드부분 

2토서 1과 같지 않다. 그러므로 프로그람은 시험 자에게 X ， y, z 는 등가가 아니 라고 정확 
하게 통보한다. 두번째 시 험실례 에서 옹근수 X ， y, z 는 모두 2이 므로 계산된 평 균값은 2 
로서 표의 값과 갈으며 따라서 프로그람은 3개 의 수가 등가이라고 정 확하게 결 론한다. 결 
국 이 프로그람을 통하는 두개의 경로는 오유가 발견되지 않고 시험되였다. 만일 데 
T 치3과 같은 시 험자료가 리용된 다면 물론 오유가 드러나게 되 였 을것 이 다. 

if ( d = = 0) 

zeroDivisionRoutine (); 

else 

x = n / d ; 


기 


x = n / d ; 
니 


그림 14-8. 나누기를 계산하는 두 코드부분 
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경로시험에서의 세번째 난점은 경로는 그 경로가 존재하여야만 시험될수 있다고 하 
는것이다. 그림 14-8 의 자)에서 보여 준 코드토막을 고찰하자. 명백히 d = 0 과 d #0 에 대 
응하는 두개의 경로가 시험되게 된다. 다음으로 그림 14-8 의 i _) 의 단일명령문을 고찰하 
자. 여기에는 하나의 경로만이 있으며 이 경로는 오유가 발견되지 않고 시험될수 있다. 
사실상 만일 프로그람작성자가 자기의 코드에서 d = 0 의 시험을 생략하면 프로그람작성 
자는 모름지기 잠재적인 위험성을 알아 채지 못하며 d = 0 의 경우는 프로그람작성자의 
시험자료에 포함되지 않게 될것이다. 이 문제는 바로 이러한 류형의 오유를 발견할 임무 
를 지니고 있는 하나의 독립적인 쏘프트웨어품질보증그룹을 가지고 있어야 할 근거로 된 
다. 

결론적으로 일부 자료들은 주어 진 경로를 시험하며 어떤 오유를 발견하고 또 다른 
자료들은 갈은 경 로를 시 험하며 오유를 발견하지 못하는것 과 갈은 제 품이 존재 하기 때 문 
에 이 실례들은《제품의 모든 경로의 시험》을 믿을수 없다는것을 보여 주고 있다. 

그러 나 경 로지향시 험 은 타당하다. 왜 냐하면 경 로지향시 험 이 오유를 드러 낼 수 있는 
시 험자료들을 선택하는것 을 본성 적 으로 방해하지 않기 때 문이 다. 

조합폭발의 원인으로 하여 명세서를 빠짐 없이 시험하거 나 코드를 빠짐 없이 시 험하는 
것은 모두 실현불가능하다. 어떤 절충이 필요한데 그것은 될수록 많은 오유들을 두드러 
지게 하는 기법들을 리용하면서 한편 모든 오유들이 탐지되였다는것을 담보하는 방법은 
없다는것을 인정하는것이다. 한가지 적당한 방법은 먼저 검은통시험(명세서시험)방법을 
리용하고 그다음 유리통시험 (코드 시험)방법을 리용하여 추가적인 시험실례를 전개하는것 
이다. 


1 4. 7. 검은통모듈시험기법 

철저한 검은통시험방법은 일반적으로 수백만개의 시험실례들을 필요로 한다. 시험에 
서의 기교는 시험실례들을 처리할수 있는 작은 모임으로 분할하여 오유를 발견할 기회를 
최소로 하는 한편 한개이상의 시험실례에 대하여 곡 같은 오유가 발견되는것으로 인한 
시험실례를 랑비할 기회를 최소로 하는것이다. 매 시험실례들은 사전에 발견되지 않은 
어떤 오유를 발견할수 있도록 선택하여야 한다. 이와 갈은 한가지 검은통기법은 등가성 
시 험 을 한계 값분석 과 결 합하는것 이 다. 

14. 7. 1 • 등가성시험과 한계값분석 

어떤 자료기지제품에 대한 명세서가 그 제품에 1부터 16,383(2 14 -1)사이의 임의의 개 
수의 기록을 조작할수 있어야 한다는것을 서술하고 있다고 하자. 만일 제품이 34개의 기 
록들과 14,870개의 기록들을 조작할수 있다면 그 제품이 이를테면 8,252개의 기록들을 애 
로없이 처리할 가망성은 충분하다. 사실 시험실례가 1부터 16,383개의 기록들사이에서 임 
의 로 선택된다면 오유가 존재하는 경우 그 오유를 발견할 가능성도 마찬가지 로 충분하다. 
거 꾸로 만일 제 품이 1부터 16,383까지 범 위 에서 선택된 임의 의 한개 시 험실례 에 대 하여 
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정확하게 동작한다면 제품은 아마도 그 범위안의 임의의 다른 시험실례에 대해서도 동작 
할수 있을것 이 다. 1부터 16,383개까지의 기록범위는 하나의 등가클라스(예 w / va/ence class ) 
를 이룬다. 즉 등가클라스는 그 클라스안의 임의의 한개 요소가 임의의 다른 요소와 마 
찬가지 로 충분히 좋은 시 험실례 로 되 게 하는 시 험실례 들의 모임 이 다. 보다 정 확하게 는 
제 품이 조작할수 있어 야 하는 특정한 개 수의 기 록개 수는 다음의 3가지 등가콜라스를 정 
의 한다. 

등가클라스 1 : 1보다 적은 기록수 

등가클라스 2 : 1부터 16,383개까지의 기록수 

등가클라스 3 : 16,383개 이상의 기 록수 

그러 면 등가클라스기 법을 리용한 자료기지제품의 시 험은 매 등가콜라스로부터 한개 
의 시 험실례 가 선택될것 을 요구하게 된다. 등가클라스 2로부터 선택된 시 험실례 는 정 확 
하게 처리되여야 하지만 반면에 클라스 1과 3으로부터 선택된 시험실례들에 대하여서는 
오유통보가 인쇄되여야 한다. 

성공한 하나의 시험실례는 앞에서 발견 못한 오유를 발견하게 된다. 이와 같은 오유를 
찾아 낼 가능성을 최소화하기 위한 한가지 결정적인 방법은 경계값분석여 value 
anafyi ) 이 다. 경험은 어떤 등가클라스의 한쪽 경계면우에 놓이는 하나의 시험실례 가 선 
택될 때에 오유를 발견할 가능성은 증가한다는것을 보여 주었다. 그렇기때문에 자료기지 
제품을 시험할 때 다음과 같은 7개의 시험실례들이 선택되여야 한다. 

시 험실례 1. 0개의 기록 : 등가클라스 1의 요소이며 경 계값에 린접하여 있다. 

시험실례 2. 1개의 기록 : 경계값 

시험실례 3. 2개의 기록 : 경계값에 린접하여 있다. 

시 험실례 4. 723개 의 기 록 : 등가클라스 2의 요소 

시험실례 5. 16,382개의 기록: 경계값에 린접하여 있다. 

시험실례 6. 16,383개의 기록: 경계값 

시험실례 7. 16,384개의 기록: 등가클라스 3의 요소이며 경계값에 린접하여 있다. 

이 실례를 입 력명세서 에 적용한다. 마찬가지 로 강력한 한가지 기 법은 출력명세서 를 
조사하는것 이 다. 실례 로 2001년에 미 국의 세 금규약에 허 용된 임의의 한 사람의 지불액으 
로부터 의 최 저 사회 보장면제액 은 보다 정 확하게 는 최 저 늙은이，생 존자, 불구자보험 ( OASDI ) 
면제액 은 0.00 딸라였고 최 대면제액은 4,984.80 딸라였는데 최 대 면제액은 총 국민소득 
80,400딸라에 대응한것 이 다. 그러므로 어떤 지불명부제품을 시험할 때 지불액 으로부터의 
사회 보장면제액 에 관한 시 험실례 들은 정 확하게 0.00 딸라와 4, 984.80 딸라의 면제액 을 생성 
할것 으로 기 대되는 입 력 자료를 포함하여 야 한다. 이 밖에 시 험자료는 0.00 딸라보다 작거 나 
4, 984.80 딸라보다 큰 면제액 을 생 성할수 있도록 설정 되 여 야 한다. 

일 반적 으로 입 력명세 서 또는 출력명세 서 에 렬거 된 매 구역 (此，요 2) 에 대 하여 다섯개 
의 시 험실례 들이 선택 되 여 야 한다. 즉 이 시 험실례 들은 각각 凡보다 작은 값，幻과 같은 
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값, 幻보다는 크고 幻보다는 작은 값，成와 갈은 값 及2보다 큰 값이 대 응한다. 어떤 항목 
이 어떤 확정적인 모임의 원소이여야 한다면(실례로 입력은 하나의 문자여야 한다.) 두개 
의 등가클라스 즉 규정된 모임의 원소와 그 모임밖의 원소가 시험되여야 한다. 명세서가 
어떤 정확한 값을 규정하고 있다면(실례로 응답뒤에 하나의 #기호가 뒤따른다.) 이때에 
도 두개의 등가클라스 즉 규정된 값과 그밖의 임의의 값이 존재하게 된다. 

입력명세서와 출력명세서를 모두 시험하기 위하여 경계값분석과 함께 등가클라스들 
을 리용하는것은 발견하지 못한 여 러 가지 잠재적 인 오유를 가지고 있는 상대적으로 작은 
시험자료를 생성하는데서 매우 가치 있는 기법으로 되는데 이러한 잠재적인 오유들은 시 
험자료들을 선택하기 위하여 그리 강력하지 못한 기법들이 리용되는 경우에 여전히 숨겨 
져 있을수도 있게 된다. 

등가성시험과정은 아래의 란에 종합한다. 


등가성시험을 진행하는 방법 

입력 및 출력명세서에 대하여 

매 개의 구역 (A 的에 대 하여 5개의 시 험실례 를 선택한다: 즉 쇼보다 작은것, Z 과 포은것， 
i 보다 크고 [/ 보다 작은것, 와 같은것, t / 보다 큰것을 선택한다. 

매 모임 5메 대하여 두개의 시험실례 즉 5의 요소와 5밖의 요소를 선택한다. 

매 정확한 값 P 에 대 하여 두개의 실례 즉 P 와 그밖의 임의의것을 선택 한다. 


1 4. 7. 2. 기능시험 

한가지 다른 형식의 검은통시험방법은 모둘의 기능에 대한 시험자료에 의거하는것이다. 

기능시 험(/뇨 wcft ’ om ?/ testing) [ Howden , 198기에서 매 개의 기능성 항목 또는 모둘에서 실 
현된 기 능은 동일 시 된다. 콤퓨터 화된 도매 소제 품을 위한 어 떤 모둘에 서 전형 적 인 기 능 
들은《다음 자료기지기록을 취하시오.》또는《직접 취급할수 있는 주문량이 재주문량 
보다 적 은가를 결정 하시 오. > 이 다. 어 떤 무기 조종체 계 에 서 어 떤 모둘은 기 능《 전술방안 
을 계 산하라.》를 포함할수 있 다. 조작체 계 의 어 떤 《 파일 이 비 였는가를 결정하라.》가 
하나의 기능으로 될수 있다. 

모둘의 모든 기 능들을 결 정한후에 시 험자료는 매 기 능을 독립 적 으로 시 험 하기 위하 
여 분할된 다. 이 제 기 능시 험 을 한걸 음 더 전진시키 자. 만일 모둘이 구조화된 프로그람작 
성에 대한 조종구조로 련결된 보다 낮은 준위의 기능들의 계층으로 구성된다면 기능시험 
은 재귀적으로 진행된다. 실례로 보다 높은 준위의 기능은 다음과 같은 형식 

< higher level function >:: = if < conditional expression > 

< lower-level function 1> ; (14.2) 

else 

< lower-level function 2 > ; 
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으로 되 여 있 다면 〈conditional expression 〉，< lower-level function 1>， < lower-level function 
2> 는 기 능시 험 에 종속되 기 때 문에 〈higher level fiinctiori > 은 14.8.1 에 서 설명 한 분기 피 복 즉 
유리통기법을 리용하여 시험될수 있다. 이러한 형식의 구조적시험은 혼성식기법이다. 즉 
저준위기 능들은 검 은통기법 을 리 용하여 시 험되 며 고준위기 능들은 유리통기법 을 리 용하여 
시험된다. 

그러 나 실 천적 으로 고준위기 능들은 이 와 갈은 구조적 인 형 식 으로 저 준위기 능들로부 
터 구성 되 지 않는다. 대 신에 저준위기 능들은 일 반적 으로 어 떤 방식 으로 얽 혀 진다. 이 러 
한 정 황에 서 의 오유를 결 정 하기 위 하여 약간 복잡한 절 차인 기 능분석 amz 切^) 

이 요구된다. 자세 한 내 용에 대 하여 서 는 문헌 [ Howden , 198기을 보시 오. 한가지 보다 
복잡한 인자는 기능들이 특히 모둘의 경계와 일 치하지 않는다는것 이 다. 그러므로 모 
둘시험과 통합시험사이의 구별이 명백치 않게 된다. 즉 하나의 모둘은 자기가 리용하 
는 다른 모둘의 기능을 동시에 시험하지 않고서는 시험될수 없다. 이러한 문제는 한 
객체의 어떤 방법이 어떤 다른 객체의 한 방법에로 어떤 통보를 보낼 때(또는 그 방 
법 을 호출할 때) 객체지향파라다임 에서도 발생한다. 

기능시험의 견지에서 모둘들사이의 우연적 인 호상관계들은 관리자측에게 있어서 접 
수할수 없는 결과들을 가져 올수도 있다. 실례 로 리정 표와 최 종기 한이 약간 불명 확하게 
되여 쏘프트웨어프로젝트관리계획에 관하여 제품의 상태를 결정하기 어렵게 될수 있다. 

14.8. 유리틍모듈시험기법 

유리 통기 법들에서 시험 실례 들은 명세 서 가 아니 라 코드의 조사에 기 초하여 선택된다. 
명령문피복, 분기피복, 경로피복을 비롯한 여러가지 서로 다른 류형의 유리통시험방법들 
이 있다. 


14. 8. 1 . 구조적시험: 명령문피복，분기피복，경로피복 

가장 간단한 형식의 유리통시험방법은 명령문피복 Cs / a / ewen / coverage ) 이다. 즉 일련의 
시험실례들이 실행되는 기간 매 명령문이 적어도 한번 실행되는 방법이다. 어느 명령문 
들이 계속 실행 되 고 있는가를 추적 하기 위하여 CASE 도구가 매 명 령 문이 시 험렬에서 몇 
번 실행되였는가를 보여 주는 기록을 유지하게 된다. PureCoverage 가 바로 이와 같은 도 
구의 한가지 실례로 된다. 

이 방법의 약점은 모든 분기들의 결과가 정당하게 시험된다는 담보가 없다는것이다. 이 
것 을 보여 주기 위하여 그림 14-9 의 코드토막을 고찰하자. 프로그람작성 자가 한개 의 오유를 
만들어 놓는다. 복합조건 s > 1 && t *4 0은 s > 1 | | t ：- = 0으로 리 해 하여 야 한다. 그 
림 에 보여 준 시험자료는 명 령문 x =9 가 오유를 발생하지 않은채로 실행되게 한다. 

명 령 문피 복에 대 한 한가지 개 선된 방법 이 분기 피 복 (6 ranc/j coverage ) 이 다. 즉 일 련의 
시험들을 실행하여 모든 분기 들이 적 어도 한번 시험된다는것을 확인하는 방법 이 다. 여기 
서 도 역 시 시 험 자가 어 느 분기 들이 시 험 되 였는가 또는 시 험 되 지 않았는가를 추적 할수 있 
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도록 하는 어떤 도구가 일반적 으로 요구된다. Generic Coverage Tool(gc/) 은 C 프로그람작 
성을 위한 분기피복의 한가지 실례이다. 이와 같은 명령문 또는 분기피복기법을 구조적 
시 험 On / c / wra / teste ) 이 라고 부른다. 

if ( s > 1 && t = = 0) 

Z ■= 9; 

시 험 자료 ; s = 2 ， t = 0. 

그림 14-9. 시 험자료를 가진 코드부분 

가장 강력 한 형 태의 구조적시 험은 경 로피복功 coverage) 이 다. 즉 모든 경로들을 시 
험 하는것 이 다. 앞에 서 보여 준마와 같이 어 떤 순환을 가진 쏘프트웨어 제 품에 서 경 로의 수는 
사실상 매우 콜수 있다. 이로부터 연구자들은 분기피복기 법을 리용할 때보다 더 많은 오유 
들을 발견하면서 시험될 경로의 수를 줄이는 방법을 연구하여 왔다. 경로를 선택하기 위한 
한가지 선택 기준은 시험 실례를 선형코드순서 렬로 제 한하는것 이 다 [Woodward, Hedley, and 
Hennell, 1980]. 이를 위 하여 먼저 조종흐름이 비 약할수 있는 점들의 모임 L 을 찾아 낸다. 
모임 L 은 입력 및 랄뢰점들과 if 또는 goto 와 갈은 분기명령문들을 포함한다. 그러면 선 
형 코드순서렬 은 L 의 요소에 서 시 작하고 L 의 요소에 서 끝나는 경 로들로 된 다. 이 방법 은 
모든 경 로들을 시험하지 않고 많은 오유들을 발견한다는 점 에서 성공적이 였다. 

시험될 경로의 수를 줄이기 위한 또 한가지 방법은 정의와 리용사이의 모든 경로피복 
( a / l - dejinition - use - path - covemge ) 0 ] [Rapps and Weyuker, 1985] . 이 기 법 에서 는 원천코드 
안에서 실례를 들어 어떤 변수 pqr 의 출현은 pqr_ 또는 read (pqr) 와 같은 변수의 정의 
( definition ) 로 표식 되 든가 y = pqr+3 또는 if (pqr < 9) error B() 와 같은 변수의 리 용(패 e) 
으로써 표식된다. 어떤 변수의 정의와 그 정의의 리용사이의 모든 경로들은 현재 하나 
의 자동도구에 의하여 식 별된다. 결 국 하나의 시 험실례 가 이 와 갈은 매 개 경 로에 설정 
된다. 정의와 리용사이의 모든 경로피복은 상대적으로 적은 시험실례들로서 많은 오유 
들을 발견하는 한가지 매우 우월한 시험기법으로 된다. 그러나 이 방법은 경로개수의 
웃 한계 가 "로 된다는 부족점 을 가지 고 있다. 여 기서 이는 제 품에서의 결정명 령 문(분기) 
의 개수이다. 웃한계를 보여 주기 위한 실례를 구성할수 있다. 그러나 인공적인 실례와 
는 반대 되 게 실 지 제 품들에 서 는 이 러 한 웃한계 가 실 현되 지 않으며 실제 적 인 경 로의 개 수 
는 d 에 비례한다는것 이 밝혀 졌다 [Weyuker, 1988a], 

달리 말하면 이 방법 에 요구되 는 시 험실례 의 개 수는 리 론적 인 웃한계 보다 훨씬 더 
작다. 결국 정 의 와 리 용사이 의 모든 경 로피 복은 실천적 인 시 험 실례 선택 기 법 으로 된다. 

구조적 시 험를 리 용할 때 시 험 자는 간단히 어떤 특정한 명 령 문，분기 또는 경 로를 사 
용하게 될 시험실례를 들고 나오지 않을수도 있다. 이 렇게 되면 모둘안에 어떤 실현불가 
능한 경로(《죽은 코드 》) 즉 임의의 입력자료에 대하여 실행될수 없는 경로가 존재하게 
된다. 그림 14-10 은 실현불가능한 경로의 두가지 실례를 보여 준다. 그림 14-10 의 가 ) 에서 
프로그람작성 자는 하나의 미누스기 호를 생 략하였다. 만일 노가 2 보다 작다면 노는 3 보다 콜 
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수 없으며 그러므로 명령문 후는 xXk 는 실현될수 없다. 류사하게 그림 14-10 의 L ) 에서 j 
는 0보다 작을수 없으므로 명령문 total = total + value [ j ] 는 결코 실현될수 없다. 즉 프로 
그람작성자는 j <10 을 시험 할 작정 이였지만 건반입력 오유가 만들어 졌다. 명령문피복을 
리용하는 시 험 자는 명 령 문이 실 현될수 없 다든가 오유들이 발견될수 없 다는것 을 인차 
깨 달을것 이 다. 

if ( k < 2) 

{ 

if ( k > 3) [ k > 一3 이 여 야 한다] 


} 


for ( I ，# 0; j <0; j ++) [ j < 10 이여야 한다] 

t 

total = total + value [ j ]; 


그림 14-10. 실행불가능한 경로의 두 실례 


1 4. 8. 2. 복잡도척도 

품질보증관점은 유리통시험에 대한 또 한가지 기법을 제공한다. 어떤 관리자에게 모 
둘 ml 이 모둘 m 2 보다 더 복잡하다고 알려 졌다고 하자. 용어 《복잡하다.》가 정의되는 
정확한 방법 에 관계 없이 관리 자는 직관적 으로 ml 은 m 2 보다 더 많은 오유를 가질수 있다 
고 믿을것이다. 이러한 착상으로부터 를퓨터과학자들은 어느 모둘이 가장 오유를 포함할 
가능성 이 있는가를 결 정 하기 위한 한가지 수단으로서 쏘프트웨어 의 복잡도에 관한 여 러 
가지 척도들을 개발하였다. 만일 어떤 모둘의 복잡도가 터무니없이 높다는것 이 알려 지 
게 되면 관리자는 틀리기 쉬운 모둘을 수정하기 보다는 처음부터 시작하는것이 값도 눅 
고 더 빠를수 있다는 리유로 하여 그 모둘을 재 설계 하고 재 실현할것 을 지 시할수 있 다. 

오유의 개 수를 예 보하기 위한 한가지 단순한 척 도는 코드의 행 이 다. 이 때 기 초로 하 
는 가정 은 코드의 한개 행 이 하나의 오유를 포함할 일정한 확률 p 가 존재 한다는것 이 다. 
만일 시험자가 코드의 한 행이 평균 2%의 오유를 포함할 가능성을 가진다고 믿고있으 
며 시험하는 모둘의 길이가 1 W 행이라면 그 모둘은 2개의 오유를 포함할것이며 이 두개 
의 길 이를 가지 는 모둘은 4개의 오유를 포함할수 있다고 추측된다는것을 의미한다. 다까 
하시 ( Takahashi ) 와 가마야스 ( Kamayachi ) 는 물론 바실 리 ( Basili ) 와 후첸 스 ( Hutchens ) 는 오유 
의 개수가 실지로 전체 제품의 크기에 관계된다는것을 보여 주었다 [Basili and Hutchens , 
1983; Takahashi and Kamayachi , 1985]. 
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제품의 복잡도에 대한 척도에 기초하여 보다 정교한 오유예보기를 찾아 내려는 시도 
들미 있었다. 한가지 전형적인 경쟁자는 2분결정(술어)의 개수에 1을 더한 맥케브 
( McCabe ) 의 주기 적 복잡도이 다 [ McCabe , 1976]. 13.12 에 서 서 술한바와 같이 주기 적 복잡도는 
본질 에 있어서 모둘에서 분기의 개수이 다. 따라서 주기 적 복잡도는 어떤 모둘의 분기피 복 
에 요구되 는 시 험실례 들에 대 한 척 도로서 리용될수 있다. 이것 이 이 른바 구조적시 험의 
기초이 다 [Watson and McCabe , 1996]. 

맥케브의 척도는 코드의 행처럼 그렇게 쉽게 계산될수 있다. 일부 실례들에서 이것 
이 오유를 예 보하기 위한 한가지 좋은 척도로 된다는것 이 제시되 였다. 즉 살의 값이 크 
면 콜수록 어떤 모둘이 오유를 포함한 가능성은 더 크다. 실례 로 월쉬는 함선전투체 계인 
Aegis 체 계 안에 있는 276개 모둘들을 분석 하였 다 [ Walsh , 1979]. 그는 주기 적복잡도 靜을 
측정 하고 삶이 10보다 크거 나 같은 23%의 모둘들이 53%의 오유를 발견하였다는것을 밝 
히였다. 이 밖에 必이 10보다 크거 나 같은 모둘들이 그보다 작은 M 값을 가진 모둘들보다 
코드행당 21% 더 많은 오유를 포함하고 있었다. 그러나 맥케브척도의 타당성은 그 리론 
적 근거 와 문헌 [ Shepperd , 1988 b , and . Sheppered and Ince , 1994] 에 서 렬거 된 여 러 가지 서 
로 다른 실험들에 기초하여 심히 문제시되였다. 

할스레 드 ( Halstead ) 의 쏘프트웨 어 과학척 도들 [ Halstead , 197刀도 오유예 보를 위 하여 리 
용되 였 다. 쏘프트웨어 과학에서 4가지 기 본요소들중의 두가지 는 모둘에 서 개 별적연산자들 
의 수 신과 개 별적 연산수의 개수 지2이 다. 전형적 인 연산자들에 #斗, X ? . if , goto 등이 
포함되 며 연산수는 사용자정 의변수 또는 상수들이다. 다른 두가지 기 본요소는 연산자의 
총수 M 과 연산수의 총 수 7 V 2 이다. 그림 14니0의 자)의 코드토막을 그림 14-11 에서 다시 
인용하였다. 그림 14-11 로부터 코드토막이 m 개의 개별적인 연산자들과 4개의 개별적연 
산수를 가지고 있다는것을 알수 있다. 연산자와 연산수의 총 개수는 각각 13과 17이 다. 
그러 면 이 4개 의 기 본요소틀은 오유예 보척 도를 위 한 입 력 으로서 리 용된 다 [ Ottenstein , 
1979]. 


if ( k < 2) 

{ 

if (k > 3) 
x = x * k ; 

} 

명백한 연산자; 

if ( < ) {> = *;} 

명백한 연산수; 

K 2 3 x 

명백한 연산수 nl 의 수 = 10 
명백한 연산수 n 2 의 수 = 4 
연산자尺1 의총수 = 13 
연산자 의 총수 네 
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그림 14-11. 그림 14-10 의 n ) 의 코드부분에 적 응된 쏘프트웨어 과학척 도 



무싸 ( Musa ), 이아니노 ( Iannino )， 오꾸모또 ( Okumoto ) 는 오유밀 도에 적 용할수 있 는 자료 
를 분석 하였 다 [ Musa , Iannino , Okumoto , 1987]. 그들은 할스테 드와 맥 케 브를 비 롯한 다수 
의 복잡성척도들이 코드행의 개수 더 정확하게는 전달가능하고 실행가능한 원천명령들의 
개수와 크게 상관되여 있다는것을 결론하였다. 달리 말하면 연구자들이 어떤 모둘 또는 
제품의 복잡도라고 자기들이 믿고 있는것을 측정할 때 엄게 되는 결론은 대체 로 코드행 
의 개수에 대한 어떤 반영 즉 오유의 개수와 강하게 상관되여 있는 어떤 측도일수 있다 
는 복잡도와 관련된 다른 문제 가 문헌 [Shepperd and Ince , 1994] 에 서 론의 된다. 더우기 
할스레 드의 척 도를 Java 또는 C ++ 와 같은 현대언어 에 적 용하는 경 우의 문제 들도 있 다. 
실례 를 들면 어 떤 구축자가 연산자인가 또는 연산수인가 하는것 이 명 백하지 않다. 

14.9. 쿄드관■심사회의와 검토 

6.2 에서는 관통심 사회 의와 검 토에 관한 하나의 유력한 실례를 제 시하였다. 그와 마찬 
가지 의 론거 가 코드관통심 사회 의 와 검 토에 관하여 성 립한다. 간단히 말하면 이 두가지 
비실행 에 기 초한 기 법 들의 오유발견능력 은 신속하고 철저하며 신속한 오유발견을 할수 
있게 한다. 코드관통심사회의 또는 검토에 요구되는 추가적 인 시간은 통합단계에서 보다 
적은 오유로 인하여 엄게 되는 생산성의 증대로서 충분히 보상된다. 더우기 코드검토사 
는 교정 유지 정 비 비 용을 95%까지 감소시 키 였 다 [ Crossman ，1982]. 

코드검 토를 진행해 야 할 다른 한가지 리유는 다른 실행 에 기 초한 시 험(시 험실례)이 
다음의 두가지 측면 에 서 극히 비 경 제 적 이 기 때 문이 다. 첫째 로, 시 간을 랑비 하는것 이 다. 둘 
째 로, 검 토는 실 행 에 기 초한 시 험 보다 앞선 생 명 주기 단계 들에 서 오유를 발견 하고 수정 할 
수 있게 한다. 그림 1-5 에 반영되 여 있는것 처 럼 오유를 보다 빨리 발견하고 수정하면 할 
수록 비 용이 더 적 게 든다. 시 험실례 들의 실행 에 많은 비 용이 든 한가지 극단한 실례 는 
NASA 의 아폴로계 획(과따 o//o Program ) 인데 여 기 에서 는 쏘프트웨 어 를 위 한 비 용의 80%가 
시험에 소비되였다 [ Dunn , 1984]. 

관통심 사회 의 와 검 토의 진행 에 관한 그이 상의 론거 들은 다음절 에 서 론의한다. 

14. 10 . 모듈시험기법들의 비교 

많은 연구들에 서 모둘시 험 을 위한 방략들을 비 교하였 다. 마이 어 스 ( Myers ) 는 검 은통시 험， 
검 은통과 유리통시험의 결 합, 3인코드관통심 사회 의 를 비 교하였 다 [ Myers , 1978 a ], 이 실험 은 
많은 경험을 가진 59명의 프로그람작성자들이 동일한 제품을 시험하는것으로써 진행되였다. 
이 세가지 기법들이 모두 오유발견에서는 동등한 결과를 가지였지만 코드관통심사회의가 
다른 두 방법보다 비용도 적고 효과적 이 라는것 이 증명되였다. 황 ( Hwang ) 은 검은통시험, 유 
리통시험，사람에 의 한 코드조사를 비교하였다 [ Hwang , 1981]. 이 세가지 기법 이 모두 동등한 
효과성을 가진다는것이 밝혀 졌으며 매 기법들은 자기의 우점과 약점을 가지고 있다. 

한가지 중요한 실험이 와썰리，쎌비의 지도밑에 진행되였다 [Basili and Selby , 198刀. 
이 방법 에서 는 황의 실험 과 마찬가지 로 검 은통시 험，유리통시험, 1인코드조사가 비 교되 였 
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다. 담당자는 32 명의 프로그람전문가와 42 명의 우수한 대학생들이였다. 매 사람이 매 시험 
기법을 한번씩 리용하여 3 개의 제품을 시험하였다. 분수차례곱설계 [Basils and Weiss, 1984] 
가 그 제 품들이 각이한 실험참가자들에 의하여 시 험된 각이한 방법 을 보상하기 위하여 
리 용되 였 다. 즉 참가자들은 갈은 제 품을 한가지 이 상의 방법 으로 시 험하지 않았다. 두 그 
를으로부터 각이한 결과들이 얻 어 졌 다. 전문프로그람작성 자들은 다른 두가지 기 법 보다 
도 코드읽기를 할 때 더 많은 오유를 발견하였으며 오유발견속도도 더 빨랐다. 두개의 
우수한 대 학생그룹이 이 실험 에 참가하였 다. 첫번째 대 학생그룹은 3 가지 기 법 에서 본질 
적 인 차이 가 없 었 으며 두번째 그룹에 서 는 코드조사와 검 은통시험 이 동등한 효과를 가지 
였으며 이 두 기법이 모두 유리통시험보다 우월하였다. 

그러나 대학생들이 오유를 발견하는 속도는 이 세가지 기법에서 모두 갈았다. 총적 
으로 코드읽 기 는 다른 두 기 법 보다 더 많은 대 면부적오유들을 발견 하였 으며 반면 에 검 은 
통시험 은 조종오유들을 찾아 낼 때 가장 성 공적이 였 다. 이 실 험 으로부터 이 끌어 낼수 있 
는 중요한 결론은 코드검토는 적어도 오유를 발견할 때에 유리통시험 및 검은통시험과 
마찬가지 로 성 공적 이 라는것 이 다. 

이 결론을 훌륭히 리용하는 한가지 개선된 기법이 무진실쏘프트웨어개발기법이다. 

14. 1 1 . 무 진 실 

무진실 기 법 (Cleanroom technique)\Lmger 1994] 은 증식 생 명 주기 모형 (3.4), 명 세 서 와 설 계 에 
대한 형식적기법들, 코드읽기 [Mills, Dyer, and Linger, 198 刀와 코드관통심사회의와 검토 (14.9) 
와 같은 비실행 에 기초한 모둘시 험 기법들을 비롯하여 여 러 가지 각이한 쏘프트웨 어개 발수 
법들을 결합한것 이 다. 무진실기법 의 중요한 측면은 어 떤 모둘은 그것 이 어 떤 검 토를 거 쳤 
을 때에야 비로서 를파일된다는것이다. 즉 모둘은 비실행에 기초한 시험이 성공한후에만 
콤파일 되여야 한다. 

이 기법은 여러가지 큰 성공을 가져 왔다. 실례로 미 해군수중체계 쎈터 (U.S.Naval 
Underwater Systems Center) 에서는 무진실기법을 리용하여 원형자동문서화체계를 개발하였 
다 [Trammel, Binder, and Snyder, 1992]. 

설계가《기능검증》을 거치는 과정에 즉 정확성증명기법들이 리용된 검토과정에 모 
두 18 개의 오유가 발견되였다 (6.5). 6.5.1 에서 제시된 검토와 갈은 비형식적증명들이 될수 
록 많이 리용되였다. 한편 완전한 수학적증명들은 검토참가자들이 검토되고 있는 설계부 
분들의 정확성을 믿지 못하는 경우에만 전개되였다. 1,820 행의 FoxBASE 코드에 대한 관 
통심 사회 의기 간에 다른 19 개 의 오유들이 발견되 였 다. 코드가 콤파일 되 였을 때 그 어 떤 
콤파일 오유도 없었 다. 더 우기 실행기 간에 는 전혀 오유가 없었 다. 이 것은 비실행 에 기 초한 
시험기법의 능력을 더욱 강조하여 주고 있다. 

이것은 확실히 하나의 인상적인 결과이다. 그러나 지적된바와 같이 소규모쏘프트웨 
어 제 품들에 적 용한 결 과들은 대규모쏘프트웨 어 제품들에 로 반드시 확대 되 는것 은 아니 다. 
그러 나 무진실기법의 경우에 보다 규모가 큰 제품들에 대 한 결과도 역시 인상적 이 다. 이 
와 관련 한 척 도는 오유시 험 률 (te 的 >jg/aw" rate) 즉 KLOC(1,000 개 의 코드행 )당 발견된 오 
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유의 총 개수인데 이것은 쏘프트웨어산업에서 상대적으로 일반적인 한가지 척도이다. 그 
러나 무진실기법이 전통적인 개발기법들에 대립하여 리용될 때 이 척도가 계산되는 방식 
에서 한가지 중요한 차이가 존재한다. 

5.6 에서 지적한 바와 같이 전통적인 개발기법들이 리용될 때 이런 모둘은 그것이 개 
발될 때에 그 작성자에 의하여 형식적으로 시험되고 그 다음에 SQA 그룹에 의하여 방법 
론적 으로 시 험된다. 코드를 개 발하는 동안 프로그람작성 자에 의하여 발견된 오유들은 기 
록되 지 않는다. 그러 나 모둘이 프로그람작성 자개 인의 워 크스테 이 션을 떠나서 실 행 및 비 
실행 에 기초한 시험를 위하여 SQA 그룹에 넘겨 진 때부터 계수기 에 발견된 오유의 개수 
를 보관해 둔다. 이와 반대 로 무진실 이 리 용될 때 에는《시 험오유》들은 콤파일을 할 때 
부터 계수된다. 그다음 오유계산은 실행에 기초한 시험전기간에 계속된다. 달리 말하면 
전통적개발기법들이 리용될 때에는 프로그람작성자에 의하여 비형식적으로 발견된 오유 
들은 시험오유률의 계산에 들어 가지 않는다. 무진실기법이 리용될 때에는 검토기간과 
콤파일 이전의 기 타 비실행 에 기초한 시 험절차기 간에 발견된 오유들은 기록되지만 그것들 
은 시 험오유률의 계 산에 들어 가지 않는다. 

무진실을 리용한 17 개의 제품에 대한 보고가 문헌 [Linger, 1994] 에 제시되였다. 실례 
로 무진실 은 350,000 행 의 Ericsson Telecom OS32 조작체 계 를 개 발하는데 리 용되 였 다. 이 제 
품은 70 개 의 림 이 참가하여 18 개 월동안에 개 발하였 다. 시 험오유률은 KLOC 당 1.0 오유에 
불과하였다. 또 다른 제 품은 앞에서 설명한 신속원형 자동문서 화체 계 이 다. 그것의 시 험 오유 
률은 1,820 행 의 프로그람에 대 하여 KLOC 당 0.0 오유이다. 17 개 제 품들을 모두 합치 면 거 의 
1 백 만행 에 이 론다. 무게 붙은 평 균오유시 험률은 KLOC 당 2.3 오유인데 링 게르 (Linger) 는 이 
것을 상당한 품질달성으로서 서술하고 있다. 이 자랑은 명백히 과장된것이 아니다. 

14. 12. 객체시험에서 제기될수 있는 문제 

객체지향파라다임을 리용할것을 주장하는 많은 리유들중의 하나는 그것이 시험에 대 
한 요구를 줄인다는것이다. 계승을 통한 재리용은 객체지향파라다임의 또 하나의 우점이 
다. 어떤 클라스가 일단 시험되면 그것은 재시험할 필요가 없다는 증거가 성립한다. 더우 
기 이와 갈은 어떤 시험된 클라스의 부분클라스내에서 정의된 새 방법들은 시험되여야 
하지만 계승된 방법들은 더 이상 시험 할 필요가 없다. 

사실 이 두가지 주장은 부분적으로만 성립하였다. 이밖에 객체들의 시험은 객체지향 
에 고유한 일정한 문제들도 발생시켰다. 여기에서는 이러한 문제점들을 론의한다. 

먼저 클라스들과 객체들의 시험과 관련한 한가지 문제점을 명백히 할 필요가 있다. 
7.7 에 서 설 명한바와 같이 하나의 콜라스는 계 승을 지 원하고 있는 하나의 추상자료류형 이 
며 하나의 객체는 어떤 클라스의 하나의 실례이다. 즉 하나의 콜라스는 구체적인 실체를 
가지지 않으며 반면에 하나의 객체 는 어떤 특정한 환경내 에서 실행되는 하나의 물리 적 인 
코드토막이 다. 그러므로 어떤 클라스에 실행 에 기초한 시험 을 진행하는것은 불가능하며 
다만 어 떤 검 토와 갈은 비 실 행 에 기 초한 시 험 만을 진 행 할수 있 다. 

정보은폐와 대다수방법들이 상대적으로 적은 행수의 코드로 이루어 진다는 사실은 
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시험에 한가지 중요한 영향을 줄수 있다. 먼저 구조화파라다임을 리용하여 개발된 어떤 
제품을 고찰하자. 현재 이와 갈은 제품은 일반적으로 약 50 개의 실행가능한 명 령들로 구 
성된다. 하나의 모둘과 제품의 나머지 모둘사이의 대면부는 인수목록이 다. 인수들는 두가 
지 종류인데 하나는 모둘이 호출될 때 그 모둘에 공급되 는 입 력인수들이고 다른 하나는 
모둘이 호출하는 모둘에 조종을 넘길 때 그 모둘이 귀환하는 출력 인수들이다. 어떤 모둘 
을 시 험하는것 은 입 력인수들에 값들을 주고 그 모둘을 호출하며 그다음 출력모둘의 값을 
예상하는 시험결과와 비교하는 과정으로 이루어 진다. 

반대 로 어 떤 《 전형 적 인》객 체 는 약 30 개 의 방법 들을 포함하고 있는데 그 대 부분은 
상대 적 으로 규모가 작으며 흔히 2 〜 3 개 의 실 행 가능한 명 령 들이 다 [Wilde, Matthews and 
Huitt, 1993]. 이 방법들은 호출자에게 값을 귀환하지 않지만 오히려 그 객체의 상태를 
변화시킨다. 즉 이러한 방법들은 그 객체의 속성(상태변수)들을 변경시킨다. 여기서 난점 
은 상태의 변경이 정확하게 수행되였다는것을 시험하기 위하여서는 그 객체에 추가적인 
통보를 보내는것 이 필요하다는것 이 다. 실례 로 1.6 에서 고찰한 은행체 계객체 를 고찰하자. 
방법 deposit 의 의미는 상태변수 account balance 의 값을 증가시키는것이다. 그러나 정보은 
폐 로 인하여 어떤 특정한 deposit 작용이 정 확하게 실행되 였는가를 시 험 하기 위한 유일한 
방도는 방법 deposit 를 호출하기전과 호출한후에 모두 방법 determine balance 를 호출하여 
은행결산이 어떻게 변화되 였는가를 보는것 이 다. 

만일 그 객체 가 모든 상태 변수들의 값을 결정 하기 위하여 호출될수 있는 방법들을 
포함하지 않고 있 다면 정 황은 더 욱 불리하다. 한가지 대 안은 이 목적 을 위하여 추가적 인 
방법을 포함시키고 그다음 추가적 인 콤파일을 리용하여 그것들을 시험목적외 에는 리용할 
수 없다는것을 확인하는것이다 (C++ 에서 이것은 #ifdef 를 리용하여 실현된다.). 시험계획 
(9 .句은 매 상태 변수의 값을 시험 기 간에 호출가능하여 야 한다는것을 규정할것 이 다. 이 요 
구를 만족시 키 기 위하여 상태 변수의 값들을 귀 환하는 추가적 인 방법 들이 설 계 단계 에 서 
련관된 클라스들에 추가되여야 할수도 있다. 그 결과로 작용가능한 상태변수들의 값을 
질문하는것으로써 어떤 객체의 어떤 특정한 방법 을 호출하는 결과를 시 험하는것 이 가능 
하게 될것이다. 

매우 놀랍게도 계승된 방법은 여전히 시험되여야 한다. 즉 어떤 방법이 적당하게 시 
험되 였 다고 할지 라도 그 방법은 어떤 부분클라스에 의하여 계 승되 고 변경되 지 않을 때 
철저한 시험 을 진행할것을 요구할수도 있다. 후자의 문제점 을 보기 위하여 그림 14-12 에 
보여 준 클라스계층들을 고찰하자. 

기초클라스 RootedTree 안에서 두개의 방법 displayNodeContents 와 printRoutine 이 정의 
되 였 는데 방법 displayNodeContents 는 방법 printRoutine 을 리용하고 있 다. 

다음으로 부분클라스 BinaryTree 를 고찰하자. 이 부분콜라스는 그것의 기초클라스 
RootedTree 로부터 방법 printRoutine 을 계 승하고 있 다. 이 밖에 하나의 새 로운 방법 
displayNodeContents 이 정의되는데 이것은 RootedTree 에서 정의된 방법을 무효로 한다. 이 
새 로 운 방 법 은 여 전 히 PrintRoutine 을 리 용 하 고 있 다 . Java 표 식 법 에 서 는 BinaryTree. 
displayNodeContents 가 RootedTree.printRoutine 을 리용하고 있 다. 
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void displayNodeContents (Node a ); 
void printRoutine (Node b ); 

// 

// 방법 displayNodeContents 는 방법 printRoutine 을 리용한다 

授 


class BinaryTree extends RootedTree 


void displayNodeContents (Node a ); 

// 

// 이 들라스에서 정의된 방법 displayNodeContents 는 

// 클라스 RootedTree 로 부터 계승된 방법 printRoutine 을 리용한다 

// 


} 

dass B 신 ancedBinaryTree extends BinaryTree 


void printRoutine (Node b ); 

// 

// (BinaryTree 로 부터 계승된)방법 displayNodeContents 는 

// 들라스 BalancedBinaryTree 안에 있는 방법 printRoutine 의 이러한 

// 국부적인 판본을 리용한다. 

// 

} 

그림 14-12. 나무계층의 Java 실현 

다음으로 부분클라스 BalancedBinaryTree 를 고찰하자. 이 부분클라스는 그 상위클라 
스 BinaryTree 로부터 방법 displayNodeContents 를 계승하고 있 다. 그러나 RootedTree 에서 
정의된것을 무효로 하는 하나의 새로운 방법 PrintRoutine 이 정의된다. displayNodeContents 
가 BalancedBinaryTree 의 문맥범위내 에서 printRoutine 을 리용할 때 C ++ 와 Java 의 령 역규 
칙들은 printRoutine 의 국부판본이 리 용되게 된다는것 을 규정 하고 있다. Java 표식 법 에서 
방법 BinaryTree . displayNodeContents 가 BalancedBinaryTree 의 사전 령 역 내 에 서 호출될 때 
그것은 방법 BalancedBinaryTree . printRoutine 을 리용한다. 그러므로 displayNodeContents 가 
BinaryTree 의 실 례 범 위 내 에 서 호출될 때 실 행 된 실제 코드(방법 printRoutine ) 는 displayNode 
Contents 가 BalancedBinaryTree 의 실 례 범 위 내 에 서 호출될 때 실 행 된 실 제 코드와 다르다. 
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이것은 방법 displayNodeContents 그자체가 Binary Tree 로부터 BalancedBinaryTree 에 의 하 
여 계승되고 변경되지 않음에도 불구하고 성립한다. 그러므로 방법 displayNodeContents 가 
하나의 BinaryTree 객 체 내 에서 철저 히 시험되 였다고 할지 라도 그 방법은 어떤 BalancedBina 
ryTree 환경 내 에서 재 리용될 때 처 음부터 재 시 험되 여 야 한다. 문제 가 좀더 복잡하게 되 여 
방법 을 각이한 시 험 실례 로써 재시험하는것 이 왜 필요한가 하는 리 론적근거 가 있다 [Peny 
and Kaiser , 1990]. 

이러한 복잡화가 객체지향파라다임을 포기할 리유로는 되지 않는다. 첫째로, 복잡화 
는 다만 방법(실례 에서 displayNodeContents 와 printRoutine ) 들의 호상작용을 통하여 생겨 
난다. 둘째 로, 이 러한 재시험 이 언제 요구되는가를 결정하는것 이 가능하다 [ Harrold , 
McGregor , and Fitzpatrick , 1992]. 이런 클라스의 한 실례가 철저히 시험되였다고 하자. 
그러면 어떤 부분클라스의 임의의 새로운 방법 또는 재정의된 방법들은 그것들이 다른 
방법들과 호상작용하는것으로 인하여 재시험되도록 기발표식을 한 방법들과 함께 시험 
될 필요가 있다. 간단히 말하면 객체지향파라다임의 리용이 시험에 대한 요구를 크게 
줄인다는 주장은 타당하다. 

다음으로 모둘시 험 에 대 한 몇 가지 관리 적의미 에 대 하여 론의한다. 

14. 13. 모듈시험의 관리측면 

매 모둘의 개발기간에 내려야 할 하나의 중요한 결정은 그 모둘을 시험하는데 얼마 
만한 시 간을 소비 하여 야 하는가 또 그로 인하여 얼마만한 자금을 소비 하여 야 하는가 하 
는것 이 다. 쏘프트웨 어공학에서 그렇게 많이 론의되 고 있는 경제적문제 들과 마찬가지 로 
비용 대 리득분석 (5.2) 이 유용한 역할을 놀수 있다. 실례로 정확성증명에 드는 비용이 어 
떤 특정한 제 품이 명세 서 를 만족시 킨다는 담보에 인한 비 용을 초과하는가에 관한 결정 은 
비용 대 리득분석에 기초하여 채택될수 있다. 비용 대 리득분석은 또한 부적당한 시험 
으로 하여 생 성된 정 식제 품에서의 오유수정비 용 대 추가적 인 시 험실례 의 실행 비 용을 비 
교하는데 리용될 수 있 다. 

어떤 특정한 모둘의 시험을 계속하겠는가 또는 모든 오유들이 사실상 제거되였는가 
를 결 정 하기 위 한 또 한가지 방법 이 있다. 믿 음성분석 기 법 들이 얼 마만한 오유들이 남아 
있는가에 대한 통계적추정을 제공하는데 리용될수 있다. 남아 있는 오유개수에 대한 통 
계적추정량을 결정하기 위하여 여러가지 각이한 기법들이 제안되였다. 이 기법의 기초를 
이루고 있는 기본착상은 다음과 갈다. 어떤 모둘이 1주일동안 시험된다고 가정하자. 월요 
일에 23개의 오유가 발견되고 화요일에 7개 가 발견된다. 수요일에는 오유가 5개 더 발견 
되며 목요일에는 2개 발견되고 금요일에는 오유가 발견되지 않는다. 오유발견률이 하루 
23개 로부터 0에 로 안정하게 감소되 기 때 문에 대 부분의 오유가 발견된것 갈으며 따라서 그 
모둘의 시 험을 중지하게 된다. 코드에 더 이상 오유가 없을 확률을 결정 하기 위 하여서는 
이 책의 독자들에게 필요한것 이상의 높은 준위의 통계수학이 요구된다. 그러므로 여기서 
는 더 자세 히 론의하지 않는다. 믿 음성분석 에 흥미 를 가지 는 독자들은 문헌 [ Gray , 1992] 
를 참고할수 있다. 
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14. 14. 모듈들 오유수정하지 않고 재작성하는 경우 

SQA 그룹의 한 성원이 어 떤 오유(오유출력)를 발견하였을 때 앞에 서 서 술한바와 같 
이 그 모둘은 오유수정 즉 오유의 시험과 코드의 정정을 위하여 원래의 프로그람작성 자 
에게 귀환되 여 야 한다. 어떤 경우에는 그 모둘을 버리고 원래의 프로그람작성 자 또는 개 
발림의 수준이 보다 높은 다른 프로그람작성자가 모둘을 처음부터 다시 설계하고 다시 
코드작성 하는것이 오히려 더 나을수 있 다. 왜 이것이 필요한가를 보기 위 하여 그림 14- 
13 을 고찰하자. 그림 에 서 그라프는 어 떤 모둘에 서 그이 상의 오유가 존재할 확률은 그 모 
둘에서 이미 발견된 오유의 개수에 비례 한다는 비직관적인 개념을 보여 주고 있다 [Myers, 
1979]. 그 리유는 무엇때 문인가를 보기 위하여 두개 의 모둘 ml 과 m2 를 고찰하자. 두 모 
둘은 근사적으로 같은 길이를 가지며 둘 다 같은 시간동안 시험되였다고 가정하자. 그리 
고 ml 에서는 다만 2 개의 오유가 발견되였지만 m2 에서는 48 개의 오유가 발견되였다고 가 
정하자. m2 에서는 ml 보다 찾아 내야 할 오유가 더많이 남아 있는것 같다. 더우기 m2 에 
대한 추가적인 시험과 오유수정은 오랜 시간이 걸리는 공정으로 될것 갈으며 m2 이 여전 
히 완전하지 못하다는 의심이 남아 있게 될것이다. 단기실행과 장기실행에서 모두 m2 를 
버리고 그것을 다시 설계 하고 다시 코드작성하는것 이 오히 려 낫다. 



이미 발견된 오유수 


그림 14-13. 오유가 발견될 확률이 이미 발견된 오유수에 
비례한다는것을 보여 주는 그라프 

모둘에 서 오유의 분포는 확실 히 균등하지 않다. 마이 어스는 OS/370 에 서 사용자에 
의하여 찾아 진 오유들의 실례를 보여 주었 다 [Myers, 1979]. 여 기 에서는 47% 의 오유 
들이 다만 4% 의 모둘들과만 관련되 여 있 다는것 이 밝혀 졌다. 엔 드레 스 (Endres) 가 IBM 
연구소에 서 DOS"S(Release28) 의 내 부시 험 과 관련하여 진행한 보다 앞선 연구와 도이 
췰 란드의 볼링 겐 (Bdblingen) 의 연구는 우와 류사한 오유분포에 서 의 불균등성 을 보여 
주었다 [Endres, 1975]. 202 개의 모둘안에서 발견된 총 512 개의 오유들가운데서 1 개의 

오유만이 112 개의 모둘에서 발견되였다. 한편 일부 모둘들은 각각 14, 15, 19, 20 개의 
오유를 가진 다는것 이 밝혀 졌다. 엔드레 스는 이 후자의 모둘에 서 3 개 가 제 품에 서 가 
장 큰 모둘들이며 그 매개가 3,000 행이상의 DOS 마크로아쌤블리어명령을 포함하고 있 
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다는것을 지적하고 있다. 그리고 14개의 오유를 가지고 있는 모둘이 사전에 매우 불 
안정하다고 알려 진 상대 적 으로 크기 가 작은 하나의 모둘이 였 다. 이 런 류형 의 모둘은 
버리고 재코드작성하여야 할 첫 후보로 된다. 

관리자측이 이러한 정황에 대처하기 위한 한가지 방도는 어떤 주어 진 모둘의 개발 
기 간에 허 용되 는 오유의 최 대개수를 사전에 결정하는것 이 다. 이 최 대 값에 도달하면 그 
모둘을 버려야 하며 그다음 어떤 경험 있는 쏘프트웨어전문가가 그 모둘을 다시 설계하 
고 다시 코드작성하여 야 한다. 이 최 대 값은 응용령역 에 따라 또 모둘에 따라 변화될 것 이 
다. 결국 어떤 자료기지로부터 하나의 기록을 읽고그 부분항목의 타당성을 검열하는 
어떤 모둘에서 발견되는 오유의 최대허용개수는 각이한 수감기들에서 오는 자료들을 
통합하고 대 포의 과녁 을 주어 진 목표에 로 지 향시키 는 땅크의 무기 계통조종체 계안의 
어 떤 복잡한 모둘에 서의 오유개 수보다 훨 씬 작아야 한다. 어 떤 특정한 모둘에 대 하여 
최 대오유합계 를 결 정 하기 위한 한가지 방도는 오유교정유지 정 비 를 요구한 류사한 모 
둘에 서의 오유자료를 조사하는것 이 다. 그러 나 어 떤 평 가기 법 이 리용되 든지간에 관리 자 
측은 이 합계가 초과되면 그 모둘은 폐기된다는것을 확인하여야 한다(다음의 《알고 
싶은 문제》를 보시 오.). 


알:2 싶 e ©제 

어떤 모듈의 개발기간에 발견되는 오유의 최대허용개수와 관련한 론의는 명백ᄀ 개발 
기간에 허용되는 최대개수를 의미하고 있다. 제품이 의뢰자에게 배포된후에 발견: 는 s _. 
유의 최대허용개수는 모든 제품의 모든 모듈에 대하여 령으로 되여야 한다. 南 오- . 없는 
코드를 의 뢰 자에 게 배 포하는것 이 모든 쏘프트웨 어 공학자들의 목표로 되 여 야 한다. 


14. 15. 실현단계에서의 CASE 도구 

실 현 단계에 서 의 CASE 도구들은 5.6 에 서 약간 자세히 론의 되 였 다. 지 면 상의 리유로 하 
여 여 기서는 그에 대 하여 되풀이하지 않는다. 

14. 16. 항공음식전문회사 실례연구 : 검은통시험실례 

그림 14-14 는 항공음식 전문회 사제 품을 위한 표본 검은통시 험 실례 들을 보여 주고 있다. 
완전한 실례모임은 부록 10에 제시된다. 시험실례들은 두가지 류형 즉 등가콜라스와 경계 
값분석에 기초한 실례들과 기능시험에 기초한 실례들이다. 

먼저 등가콜라스와 경 계 값분석 을 고찰하면 첫 번째 모임 의 다섯개 시 험실례 들은 등가 
콜라스로부터 선택 되여 어떤 승객의 세례명 ( firstName ) 이 卜15개의 문자로 구성 되여 있 
는가를 검열한다. 다섯번째 등가콜라스는 요구들에 만일 어떤 이름이 15개 문자이상으로 
구성된다면 어떤 현상이 발생하는가를 서술하지 않고 있다는것을 반영하고 있다. 같은 
모임 안의 등가클라스들은 어 떤 승객 의 이 름 ( lastName ) 에 마찬가지 로 적 용될 수 있 다. 
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ne 나 lastName 에 대 한 등가믈라스 


:1 개 문자 

오유 

개 문자 

수용고 

〜 15 개 문자 

수용고 

5 개 문자 

수용고 

15 개 문자 

명시 5 

:ionID 에 대 한 등가콜라스 : 


:6 개 문자 

오유 

6 개 문자 

오유 


개 문자(모두 자모가 아님) 오유 
개 문자(모두 자모) 수용고 


성 

jservationID 가 이 미 존재 한다는 여 
국떤 특별비행을 위한 좌석번호가 
assengerlD 가 자료기지에 이미 존: 
assengerlD 가 자료기지에 이미 존: 

사 

;servationID 를 자료기 지에서 찾을 ■ 
: servationID 를 자료기 지에서 찾을- 

사목록의 조사 

:1■료기 지 에 존재하지 않는 비 행날. 
:1■료기 지 에 존재하는 비 행날자와 

서의 조사 

;servationID 를 자료기 지에서 찾을 ■ 
reservationlD 를 자료기 지 에 서 찾을 n 

현시 

매 보고서에 대하여 출발날자 (' 
10/1 990) 보다 더 늦어 지는 보고' 
조달자와 탑승보고서에 대하여 : 
호에 대 한 보고서를 현시 
25h 조달자목록의 현시 




16. 주문한 식 사가 한번 이상 오르지 않은 승객 이 여 러 명 일 때 비 적 재 보고서 를 현시 
(갈은 날자에 여 러명의 예 약이 발행할 때 에도 우의 작용을 시도한다.) 

17. 품질 이 5급이하라고 생 각되는 식사가 오른 경우의 승객 이 자료기지안에 없을 때 
저품질식사에 대한 보고서를 현시 

18. 품질 이 5급이하라고 생 각되 는 식 사가 오른 경 우의 승객 이 자료기 지안에 여 러 명 
일 때 저품질식사에 대한 보고서를 현시 

19. 퍼센트에 대한 보고서를 현시 

20. 자료기지에 저염식사항목이 없을 때 저염식사에 대한 보고서를 현시 

21. 자료기지안에 저염식사항목이 여 러 개 있을 때 저염식사에 대 한 보고서를 현시 


그림 14-14. 항공음식 전문회 사제 품을 위 한 검 은통시 험 실례(계 속) 

시험실례들이 명세서 에서의 결함을 로출시킬 때 명세서 에 되돌아 가 그것을 변경시 
키는것 이 필요하다. 항공음식전문회 사제 품에서 명세서는 사용자가 15개 문자이 상의 이 름 
을 입 력하려 고 하면 어 떤 오유통보가 인쇄 되 여 야 한다는것 을 서 술하여 야 한다. 검 은통시 
험실례 들에 의하여 로출된 명세서 의 오유를 정정하기 위하여 필요한 변경조작은 단순하 
기때문에 여기서는 생략하기로 한다. 

두번째 모임 안의 4개 의 등가클라스들은 예 약식 별 자 ( msem 泊^正))가 정 확히 6개 의 자 
모문자들로 구성되 여 있는가를 검 열 하는데 리 용된다. 류사한 등가클라스들이 명세 서안의 
기 타 설명 문들을 검 열하기 위한 시 험실례들을 선택하는데 리 용된다. 완전한 모임 은 부록 
10에 게 시한다. 

다음으로 기능시험을 고찰하자. 명세서로부터 끌어 낸 21개의 기능들을 그림 14-14 
에 렬거한다. 이 절에서 보여 주고 있는바와 같이 검은통시험실례들은 명세서안의 오유 
들을 밝혀 내는데 리용될수 있기때문에 명세서가 완성되자마자 곧 이러한 기능시험실례 
들이 개발되였다는것을 알아 차리는것 이 중요하다. 

매 시 험 계 획 에서 한가지 중요한 요소는 검 은통시 험실례 들이 될수록 빨리 작성 된다는 
데 대한 규정이다. 만일 제품전체에 대한 어떤 계약서가 서명된다면 이것은 명세서가 승 
인되자마자 곧 진행된다. 한편 제품의 완성에 관한 계약서는 일단 의뢰자가 기한과 비용 
평 가에 동의하면 즉 명세서작성단계의 마감에 서명된다. 그다음 실현 및 통합단계 에서 
SQA 그룹이 리용할수 있도록 검 은통시험실례 들이 작성 된다. 

14. 17. 실현단계에서의 난관 

역설적으로 들릴지 모르지만 실현단계에서의 한가지 중요한 난관은 실현단계의 선행 
단계 들에 서 만족되 여 야 한다. 제 8장에 서 설명한바와 같이 코드의 재 리용은 쏘 프트웨 어 의 
개 발비용과 배포시 간을 줄이 기 위한 한가지 효과적 인 방도로 된다. 그러 나 이것은 실현 
단게 처 럼 늦게 시 도하게 되 면 코드의 재 리용을 실 현 하기 어 렵 다. 

실례로 언어 L 로 어떤 제품을 실현하기로 결정된다고 하자. 이제 과반수의 모둘이 
실현되고 시험된후에 관리자측이 쏘 프트웨 어제품의 도형사용자대면부를 위 하여 프로 그람 
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패키지 P 를 리용하기로 결정한다고 하자. P 의 루린들이 아무리 강력하다 할지라도 만일 
그 루린들이 L 와 결합하기 어 려 운 언어 로 작성된다면 그 루린들은 쏘프트웨 어제품에서 
재 리용될 수 없 다. 

비록 언어의 호상리용가능성이 문제로 되지 않는다고 하여도 재리용될 항목이 설계 
에 정 확히 부합되 지 않는 한 어 떤 현존하는 모둘을 재 리용하려 고 할 때 일부 문제 점 이 
존재하게 된 다. 새 로운 모둘을 처 음부터 작성할 때보다 현존하는 모둘을 변경시키 는데 
더 많은 품이 요구될수 있다. 

그러 므로 모둘의 재 리용은 맨 처 음부터 쏘프트웨어 제품안에 병 합되 여 들어 가야 한 
다. 재리용은 명세작성에 대한 제약으로뿐만아니라 사용자의 요구로 되여야 한다. 쏘프트 
웨 어프로젝 트관리 계 획 (9.4) 도 재 리 용을 병 합하여 야 한다. 또한 설 계문서 는 어 느 모둘이 실 
현되 며 어 느 모둘이 재 리용되 는가를 서 술하여 야 한다. 

결국 이 절의 서 두에서 서 술한바와 같이 비록 모둘의 재 리용이 실현단계에서의 한가 
지 중요한 난관으로 된 다고 하여 도 모둘의 재 리용은 요구사항확정 , 명세 서작성 및 설계 
단계들에 병합되여야 한다. 


요 약 

이 장에서는 개발림 에 의 한 어 떤 제 품의 실현과 관계 되 는 여 러 가지 론의들을 제시하 
고 있다. 여기에는 프로그람작성언어의 선택문제가 포함된다 (14.1). 4 세대언어에 대한 문 
제 가 14.2 에 서 약간 자세 히 론의 된 다. 휼륭한 프로그람작성실 천문제 를 14.3 에 서 서 술하며 
실 천적코드작성표준에 대 한 요구가 14.4 에 제 시된다. 그다음 모둘의 재 리용과 관련한 설 
명을 진행한다 (14.5). 시험실례들은 체계적으로 선택되여야 한다는것이 서술된다 (14.6). 검 
은통시험, 유리통시험，비실행에 기초한 시험 등 여러가지 시험기법들이 서술되며 (14.7, 
14.8, 14.9) 그다음 그 기 법 들을 비 교한다 (14.10). 무진실기법 을 14 丄 1 에서 서 술한다. 객 체 
시 험 문제 를 14.12 에 서 론의하며 뒤 이 어 모둘시 험 에 관한 관리 측면문제 가 론의 된다 (14.13). 
모둘을 오유수정하지 않고 재작성 하기 위한 문제 를 14.14 에서 서술한다. 실현단계에서의 
CASE 도구들을 그다음에 언급한다 (14.15). 14.16 에서 항공음식전문회사제품들에 대한 실례 
연구가 론의된다. 이 장은 실현단계에서의 난점에 대한 한가지 분석으로써 결속된다 
(14.17). 


보 충 

4GL 에 대 한 보다 넓은 정 보원천은 문헌 [Martin, 1985] 이 다. 4GL 과 관련한 43 개 기 업 
체 들의 립장은 문헌 [Guimaraes, 1985] 에 서 보고 하고 있 다. 문헌 [Klepper and Bock, 1995] 
에는 McDonnell Douglas 이 어떻게 3GL 보다 4GL 이 생산성이 더 높은가를 서술하고 있다. 
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좋은 프로그람작성 실천과 관련한 훌륭한 문헌은 [Kemighan and Plauger , 1974, and 
McConnell , 1993] 이 다. 

실행에 기초한 시험과 관련된 보다 초기의 중요한 연구는 문헌 [ Myers , 1979] 이다. 일 
반적으로 시험에 대한 정보는 문헌 [ Beizer , 199이 에 있 다. 기능시험에 대하여서는 문헌 
[ Howden , 198기에 서 서 술하여 주고 있고 구조적 기 법 에 대 하여 서 는 문헌 [ Clarke , Podgurski , 
Richardson , and Zeil , 1989] 에서 비 교하여 주고 있 다. 검 은통시 험 에 대 하여서는 문헌 [ Beizer , 
1995] 에서 상세하게 서 술하여 주었 다. 검 은통시험실례의 설계 와 관련하여 문헌 [ Yamaura , 
1998] 에서 서술하여 주었다. 기능적시 험과 쏘프트웨 어품질과 관련한 여 러 가지 피 복측도들 
사이 관계 에 대 하여 문헌 [Horgan London , and Lyu , 1994] 에 서 론의 하였 다. 검 은통시 험 에 관 
한 형 식적 인 연구방법 에 대 하여서는 문헌 [Stocks ^ Carrington , 1996] 에서 론의하였다. 

무진실과 관련하여서는 문헌 [ Linger , 1994] 에서 론의하였다. 유지정비단계에서의 무 
진실의 리 용과 관련하여 문헌 [ Sherer , Kouchakdjian , and Arnold , 1996] 에 서 서 술하여 주 
었다. 무진실의 비평과 관련하여 문헌 [ Beizer , 199기에서 고찰하여 주었다. 

쏘프트웨 어 믿 음성 에 대 하여 문헌 [Musa and Everett , 1990] 에 서 소개 하여 주고 있 다. 
그리 고 쏘프트웨 어믿 음성공학과 관련 한 국제 토론회회 보에는 쏘프트웨 어믿 음성 과 관련 한 
아주 다양한 기 사들을 게재 하고 있다. 또한 믿음성 에 대 하여서 는 IEEE Software 1995년 5 
월호와 IEEE Computer 1996년 11월호에 여러건의 기사들이 있다. 

쏘프트웨 어 시 험 및 분석 과 관련 한 국제토론회회 보에는 시 험 과 관련 한 여 러 가지 문제 
점 들이 상세하게 서 술되 였 다. 

객체의 시험과 관련한 서로 다른 연구방법들의 조사에 대하여서는 문헌 [ Turner , 1994] 
에서 찾아 볼수 있다. 이 주제 에 대한 두개의 중요한 론문은 문헌 [Peny and Kaiser , 1990, 
and Harrold , McGregor , and Fitzpatrick , 1992] 에 있다. 문헌 [ Beizer , 1995] 는 앞에서도 언급 
한바와 같이 객체지향쏘프트웨어 에 대 한 검은통시험 을 포함하고 있다. Communications of 
the ACM 1994 년 9 월호에는 객체지 향쏘프트웨 어시험과 관련된 많은 기사들이 들어 있다. 

실현단계에서 의 척 도와 관련한 맥케 브의 주기 적복잡도는 문헌 [ McCabe , 1976] 에서 
처음으로 고찰하였다. 설계 단계 에서의 척도에 대 한 확장은 문헌 [McCabe and Butler , 
1989] 에 서 서 술해 주었 다. 쏘프트웨어 과학과 주기 적복잡도에 대 한 타당성 을 질 문하는 기 
사들은 문헌 [ Shepperd , 1988 b ; Weyuker , 1988 b ; and Shepperd and Ince , 1994] 에 들어 있다. 
코드검 토를 관리 하는 척 도에 대 하여 서 는 문헌 [Barnard and Price , 1994] 에 서 서 술하여 주 
緣다. 


문 제 


14 . 1 . 교원 이 당신 에 게 브로드렌 즈지역 아동병 원제 품을 실 현 할것 을 요청하였 다(부록 
1). 이 제 품을 실현하기 위하여 당신은 어 떤 언어 를 선택하겠는가? 그 리유는 무엇 인가? 





당신이 리용할수 있는 여 러가지 언어들에 대하여 그것들의 리득과 비용을 렬거하시오. 

14 . 2 . 승강기문제 에 대 하여 문제 14.1 을 반복하시 오 (11.6.1). 

14 . 3 . 자동서 고순환체 계 에 대 하여 문제 14.1 을 반복하시 오 (8.7). 

14 . 4 . 어 떤 은행설명 문의 정 확성 여부를 결정하는 제 품에 대 하여 문제 14.1 을 반복하 
시오. 

14 . 5 . 자동출납기에 대하여 문제 14.1 을 반복하시오 (8.9). 

14 . 6 . 당신 이 최 근에 작성한 어 떤 모둘에 서 두설 명 문을 추가하시 오. 

14 . 7 . 어 떤 1인쏘프트웨 어 생 산회 사에 대 한 코드작성표준은 300명 의 쏘프트웨어 전문가 
를 가진 개발기업체의 코드작성표준과 어떻게 차이나는가? 

14 . 8 . 집 중치 료기 구를 위한 쏘프트웨어 를 개 발하고 유지정 비하는 어 떤 쏘프트웨 어 회 
사에 대 한 코드작성표준은 회 계제 품을 개 발하고 유지정 비하는 개 발기 업 체의 코드작성표 
준과 어떻게 차이나는가? 

14 . 9 . 나우르 ( Naur ) 의 본문처 리 문제 (6.5.2) 를 위 한 검 은통시 험 실례 들을 작성 하시 오. 매 
시험실례 에 대 하여 무엇 이 시 험되는가와 그 시험실례의 예상되는 결과를 서술하시 오. 

14 . 10 . 문제 6.15 에 대한 당신의 풀이(또는 지도교원이 배포한 코드) 를 리용하여 명 령 
문피 복시 험 실 례 들을 작성 하시 오. 매 시 험 실 례 에 대 하여 무엇 이 시 험 되 는가와 그 시 험 실 
례의 예상되는 결과를 서술하시오. 

14 . 11 . 분기피 복에 대 하여 문제 14.10 을 반복하시 오. 

14 . 12 . 정의와 리 용사이 의 모든 경로피복 (all-dejinition-use-path coverage ) 에 대하여 문 
제 14.10 을 반복하시오. 

14 . 13 . 경로피복에 대하여 문제 14.10 을 반복하시오. 

14 . 14 . 선형 코드순서렬 에 대 하여 문제 14.10 을 반복하시 오. 

14 . 15 . 문제 6.15 에 대한 당신의 풀이(또는 지도교원이 배포 하는 코드) 에 대한 흐름도 
표를 작성하시오. 

그 주기 적 복잡도를 결 정하시 오. 만일 분기 수를 결 정할수 없 으면 흐름도를 하나의 방 
향그라프로서 고찰하시 오. 릉의 개수 e , 마디점개수 n , 련결요소의 개수 c 를 결정하시 오 
(매 방법 은 하나의 련결요소를 이 룬다.). 주기 적 복잡도 厂는 문헌 [ McCabe , 1796] 에 의해 
다음과 같이 주어 진다. 


V = e-n +2c 

14 . 16 . 그림 14-10 의 니의 코드토막에 대한 할스레드 ( Halstead ) 의 4가지 기본척도를 
결 정 하시 오. 

14 . 17 . 당신은 1인쏘프트웨 어회 사의 주인이 고 유일한 직 원이 다. 당신이 5.6 에 서 술된 
프로그람작성 도구집 을 구입하였 다. 중요한 순서 로 5가지 능력 을 렬 거 하고 그 리유를 밝 
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히 시오. 

14.18. 당신은 17,500명 의 종업 원을 가지 고 있 는 매 우 큰 쏘프트웨 어회 사의 쏘프트 
웨어기술부의 부책임자이다. 5.6 에서 서술한 프로그람작성도구집의 능력을 어떻게 평가 
하는가? 이 문제 에 대 한 당신의 대 답과 선행한 대 답사이 의 모든 차이 에 대 하여 설명하 
시오. 

14.19. 당신은 쏘프트웨어개발기업체를 위한 SQA 경영자로서 시험기간에 어떤 주어 
진 모둘에서 발견할수 있는 최대오유개수를 결정할 책임을 지고 있다. 만일 이 최대값이 
초과되 면 그 모둘은 다시 설계 되 고 다시 코드작성 되 여 야 한다. 어 떤 판정 기 준을 리용하 
여 주어 진 모둘에 대 한 최 대오유개 수를 결 정하겠는가? 

14.20. (과정 안상 목표) 문제 11.15 또는 12.9 에 명 시된 제 품을 위한 검 은통시험실례 들 
을 작성하시오. 매 시험실례에 대하여 무엇이 시험되는가와 그 시험실례의 예상되는 결 
과를 서 술하시 오. 

14.21. (실례연구) 15.13 에 서술한 항공음식전문회사제품의 실례연구실현에 대한 복제 
본이 주어 진다. 이 제 품에 대 한 명 령 문피 복시 험실례 를 작성 하시 오. 매 시 험실례 에 대 하 
여 무엇 이 시 험되는가와 그 시 험실례의 예상되는 결과를 서술하시 오. 

14.22. (실 례연구) 분기피 복에 대 하여 문제 14.21 을 반복하시 오. 

14.23. (실례연구) 정의와 리용사이의 모든 경로피복에 대하여 문제 14.21 을 반복하 
시오. 

14.24. (실 례연구) 경 로피 복에 대 하여 문제 14.21 을 반복하시 오. 

14.25. (실 례연구) 선행코드순서렬 에 대 하여 문제 14.21 을 반복하시 오. 

14.26. (쏘프트웨 어공학독본) 교원 이 문헌 [ Beizer , 199기의 복제본을 배 포할것 이 다. 무 
진실 에 대 한 당신의 립장은 무엇 인가? 
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제 1 5장. 실현 및 틍합단계 


지금까지 실현과 통합은 두개의 독립적이고 분리된 단계로 취급되여 왔다. 제시된 
방법들에서 매개의 모둘(또는 객체)은 프로그람작성림의 한 성원에 의하여 실현되고 쏘 
프트웨 어품질보증그룹에 의하여 시험된다. 그다 음 통합단계에서 모둘들이 합쳐 지고 전 
체로서 시험된다. 사실상 이 방법은 쏘프트웨 어를 개발하기 위한 좋은 방법으로 되지 못 
한다. 그대신 실현과 통합단계는 병렬로 수행되여야 한다. 병렬적방법이 이 장의 기본주 
제로 된다. 

이 장에서는 실현 및 통합단계技 o « and integration 에 대하여 언급한 

다. 엄격히 말하여 이와 갈은 단계는 없다. 실현과 통합은 설계와 계획이 구별되는것과 
마찬가지 로 서 로 다른 활동이 다. 그러 나 지 금부터 실현 및 통합단계 라는 용어 를 리용하 
여 설계단계와 통합단계가 병렬로 진행될 때에 수행되는 활동을 서술한다. 

여 기 에서는 통합 및 통합시 험 에 관한 기본개 념들이 소개되며 다음으로 객체지향제 품 
들이 어떻게 실현되고 통합되는가를 서술한다. 

15. 1 . 실현 및 틍합에 대한 소개 

그림 15-1 에 묘사된 제품을 고찰하자. 이 제품을 개발할 때의 한가지 방법은 매개의 
모둘은 개 별적 으로 코드작성 하고 시 험하며 그다음 13개 의 모둘을 모두 결 합하고 전체 적 
인 제 품을 시 험하는것 이 다. 이 방법 에 는 두가지 난점 이 있 다. 첫 째 로, 모둘 a 를 고찰하자. 
모둘 a 는 모둘 b , c , d 를 호출하기때문에 자기자신에 대하여 시험될수 없다. 그러므로 모 
둘 a 를 시험 하기 위하여서는 모둘 b , c , 이는 대용체0야均로서 코드작성되 여 야 한다. 가장 
단순한 형식으로서 하나의 대용체는 하나의 빈 모둘이다. 보다 유효한 하나의 대용체는 
module displayRadarPattem called 와 같은 하나의 통보를 인쇄한다. 
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그림 15-1. 전형적인 모듈호상접속도 



무엇보다도 하나의 대용체는 사전에 계획된 시험실례들에 대응하는 값들을 귀환하여 
야 한다. 이제 모둘 노를 고찰하자. 모둘 노를 자기자신에 대하여 시험하기 위하여서는 어 
떤 구동프로그람 즉 만일 시험 하는 모둘이 귀환하는 값들을 검열할수 있다면 그 모둘을 
한번 또는 그이상 호출하는 하나의 모둘이 필요하다. 이 와 류사하게 모둘 d 를 시 험하려 
면 하나의 구동프로그람과 두개 의 대 용체 가 필요하다. 그러 므로 실 현과 통합을 분리하여 
진행할 때 발생하는 한가지 문제는 모둘시험 이 완성된후에 모두 버리게 되는 대용체 들과 
구동프로그람을 작성 하는데 품을 들여 야 한다는것 이 다. 

실 현 단계 가 완성 된 다음 통합단계 가 시 작될 때 발생하는 보다 중요한 두번째 난점 은 
오유의 고립이 결여되여 있는것이다. 만일 전체적인 제품이 어떤 특정한 실례에 대하여 
시험되 여 실패 로 된다면 오유는 13개의 모둘 또는 13개의 대면부중에서 임의의것 에 존재 
할수 있다. 어떤 보다 큰 제품 이를테면 103개의 모둘과 108개의 대면부를 가진 제품에 
서 는 오유가 존재할수 있는 개 소가 211개 이 상이 다. 

이 두가지 난점에 대한 해결방안은 모둘시험과 통합시험를 결합하는것 이 다. 

15. 1 . 1 . 내리실현 및 틍합 

내리실현 및 통합에서 만일 모둘 mAbove 가 모둘 mBelow 를 호출한다면 mAbove 는 
mBelow 에 앞서 실현되고 통합된다. 그림 15_1에 보여 준 제품이 하강식으로 실현되고 
통합된다고 하자. 한가지 가능한 하강식순서짓기는 a , b , c , d , e , f , g , h , i , j , k , 1, m 이다. 
먼저 모둘 a 가 코드작성되고 대용체로 실현된 b , c , d 와 함께 시험된다. 그다음 대용체 b 
는 모둘 b 로 확장되여 모둘 a 와 결합되며 대용체로 실현된 모둘 e 와 함께 시험된다. 실 
현 및 통합은 이러한 방식으로 모든 모둘들이 제품안에 통합되여 들어갈 때까지 진행된 

다. 또 한가지 가능한 하강식 순서 짓 기 는 a , b , e , h , c , d , f , i , g , j , k , 1, 이이 다. 이 순서 짓 

기에 대하여 실현 및 통합의 부분들은 다음과 같은 방식으로 병렬로 진행된다. 모둘 a 가 
코드작성되고 시험된 다음에 한명의 프로그람작성자가 모둘 a 를 리용하여 b , e , h 를 실현 
하고 통합할수 있으며 한편 다른 프로그람작성 자가 a 를 리용하여 c , d , f , i 에 대 하여 병 

렬 로 작업할수 있 다. 일 단 d 와 f 가 완성 되 면 세 번째 프로그람작성 자가 g, j , k , 1, m 에 대 

하여 작업을 시 작할수 있다. 

모둘 a 가 그자체 로서 어떤 특정한 시 험실례 에 대 하여 정 확하게 실행된다고 가정 하자. 
그러나 b 가 코드작성되여 제품에 통합되여 들어 가면 그 제품은 모둘 a 와 b 가 서로 결합 
되 여 이루어 지는데 그다음 같은 시 험자료가 제 시되는 경우 그 제품은 실패한다. 오유는 
두 개소중에서 어느 하나에 있을수 있다. 즉 모둘 b 든가 또는 모둘 a 와 b 사이의 대면부 
에 있을수 있다. 일반적 으로 어떤 모둘 mNew 가 지 금까지 시 험된것 들에 추가되 여 사전에 
성공하였던 어떤 시험 실례 가 실패하는 경우에 는 언제 나 오유는 거의 확정 적 으로 mNew 
든가 mNew 와 제품의 기 타 부분사이의 대면부들에 놓이게 된다. 결국 내 리실현 및 통합 
은 오유고립화를 지원한다. 

내 리 실현 및 통합의 다른 우점 은 기 본설 계오유들이 일찌 기 드러나게 된 다는것 이 다. 
어떤 제품의 모둘블은 두개의 그룹 즉 론리모둘과 조작모둘로 가를수 있다. 론리모둘 


491 





{logic module ) 은 본질에 있어서 제품의 조종측면에 대 한 결심 채 택흐름을 병 합하고 있다. 
론리 모둘들은 일 반적 으로 모둘호상접 속도에 서 뿌리 에 가깝게 배 치 되 여 있는 모둘들이다. 실 
례 로 그림 15-1 에서 a , b , c , d 를 론리모둘로 기대 하는것 이 타당하며 g 와 j 도 론리모둘로 될 
수 있을것 같다. 한편 조작모둘 ( operafewa / module ) 은 제 품의 실제 적 인 조작을 수행한다. 
실례로 하나의 조작모둘은 getlineFromTerminal 이든가 measureTemperatureOfReactorCore 로 
이름 지어 질수 있다. 조작모둘들은 일반적 으로 모둘호상접속도의 잎에 가까운 보다 낮은 
준위 에 서 찾아 진다. 그림 15-1 에 서 모둘 e , f , h , i , k , 1, 이은 조작모둘들이다. 

조작모둘들을 코드작성 하고 시 험 하기전에 론리 모둘들을 코드작성 하고 시 험하는것 이 중 
요하다. 이것은 임의의 중요한 설계오유들이 일찌기 로출되게 할것이다. 전체 제품이 완성 
된 다음 어떤 중요한 오유가 발견된다고 가정하자. 그러면 제품의 많은 부분을 재작성하여 
야 할것이다. 특히 조종흐름을 구현하고 있는 론리모둘을 재작성하여야 한다. 아마도 대부 
분의 조작모둘들은 재구성된 제품내에서 재리용가능할수 있다. 실례로 getlineFromTerminal 
또는 measureTemperatureOfReactorCore 와 같은 모둘은 그 제품이 어떻게 재구성된다고 하 
더라도 필요하다. 그러나 조작모둘이 제품의 다른 모둘과 련결되는 방법은 변경되여야 
할수 있으며 이것은 불필요한 작업을 야기시킨다. 그러므로 설계오유가 일찌기 발견되면 
될수록 그 제품을 정정 하고 늦어 진 개 발일정을 보상하는것 이 더욱 빨라 지고 비용이 더 
적게 든다. 모둘들이 하강식전략을 리용하여 실현되고 통합되는 순서는 본질에 있어서 
론리모둘들이 실지로 조작모둘보다 앞서 실현되고 통합된다는것을 담보한다. 왜냐하면 
모둘호상접 속도에 서 론리 모둘은 거 의 언제 나 조작모둘의 선조로 되 기 때 문이 다. 

그러나 내리실현 및 통합은 한가지 결함을 가지고 있다. 즉 잠재적으로 재리용가능 
한 모둘들이 적당하게 시 험되지 않을수 있다. 철저히 시 험되였다고 부당하게 인정된 어 
떤 모둘을 재 리 용하는것은 그 모둘을 처음부터 작성하는것보다 더 비 경제적일수 있다. 
왜 냐하면 어떤 모둘이 정 확하다는 가정은 그 모둘이 실패할 때 그릇된 결론에 로 이끌어 
갈수 있기때문이다. 즉 불충분하게 시 험되여 재리용된 모둘을 의심할 대신에 시 험 자는 
오유가 그밖의 다른데 있다고 생각하면서 결국은 노력을 랑비할수 있다. 

론리모둘은 특정한 일부 문제에 한정되여서 다른 련관범위에서는 리용할수 없을것 
같다. 그러 나 조작모둘은 특히 그것 이 비형 식적응집도를 가지는 경우에 (7.2.7) 미 래의 제 
품들에 재리용될수 있으며 그때문에 철저한 시험을 필요로 한다. 유감스럽게도 조작모둘 
은 일반적으로 모둘호상접속도에서 하위준위모둘이며 따라서 상위준위모둘처럼 자주 시 
험되지 않는다. 실례 로 184개 의 모둘이 있 다면 뿌리모둘은 184번 시 험될것 이 며 반면에 
제 품에 마지 막으로 통합된 모둘은 한번만 시 험될것 이 다. 내 리 실현 및 통합은 조작모둘에 
대 한 부적 당한 시 험 으로 인 하여 재 리 용을 위 험 한 일 로 만든다. 

만일 제품이 잘 설계되면 정황은 더욱 악화된다. 사실 설계가 좋으면 좋을수록 모둘들 
은 더 불철저하게 시 험 되는것 같다. 이 것을 보기 위하여 모둘 computeSquareRoot 를 고찰하 
자. 이 모둘은 두개의 인수를 가지 고 있 다. 즉 2차뿌리 로 결정해 야 할 류점 수 x 와 x 가 부 
수일 때 ttue 로 설정되 는 errorFlag 이 다. 나아가서 computeSquareRoot 가 모둘 m 3 에 의 하여 
호출되며 모둘 m 3 은 다음의 명 령 문을 포함하고 있다고 가정 하자. 
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If ( x 〉=0) 

y = computeSquareRoot ( x , errorFlag ); 

달리 말하면 computeSquareRoot 는 표의 값이 부수가 아닌 이상 절대로 호출되지 않으 
며 그러므로 이 모듈은 부의 x 값으로는 절대로 시험되지 않기때문에 그것이 정확하게 기 
능을 수행하는가를 알수 없다. 모둘호출이 이러한 종류의 어떤 안정성시험을 포함하는 
설계형식 을 방어프로그람작성이 라고 부른다. 방어 프로그람작성 의 
결과로 만일 모둘들이 하강식 으로 실현되 고 통합된 다면 종속조작모둘들은 철 저하게 시 험 
되 지 않을것 갈다. 방어 프로그람작성 에 대 한 한가지 대 안은 믿 음성구동설 계 를 리용하는 
것이다 (1 .句. 여기에서는 필요한 안정성시험 이 호출자가 아니라 호출된 모둘안에 작성되 
여 들어 간다. 다른 하나의 방법 은 호출된 모둘에 서 단언들을 리 용하는것 이 다 (6.5.3). 

1 5. 1 . 2. 올리실현 및 틍합 

올리실 현 및 통합에 서 만일 모둘 mAbove 가 모둘 mBelow 를 호출한다면 mBelow 는 
mAbove 보다 앞서 실현되고 통합된다. 그림 15-1 에서 가능한 한가지 상승식순서짓기는 1, 
m , h , i , j , k , e , f , g , b , c , d , a 이 다. 이 제 품을 어 떤 림 이 코드작성 하도록 하자면 보다 좋 
은 한가지 상승식순서짓기는 다음과 같이 진행된다. h , e , b 가 한 프로그람작성자에게 주 
어 지며 i , f , c 는 다른 프로그람작성 자에 게 주어 진다. 세 번째 프로그람작성 자는 1, m , j , 
k , g 로써 시작하여 그다음 d 를 실현하고 자기의 작업결과를 두번째 프로그람작성 자의 작 
업결과와 통합한다. 마지막으로 b , c , d 가 성공적으로 통합될 때 a 는 실현되고 통합될수 
象다. 

결국 조작모둘들은 상승식전략이 리용될 때 철저히 시험된다. 이밖에 시험은 호출모 
둘이 방어적 으로 프로그람작성되 는 오유차폐 에 의 해서 가 아니 라 구동프로그람의 도움으 
로 수행된다. 비록 올리실현 및 통합이 내리실현 및 통합의 기본난점을 해결하고 내리실 
현 및 통합의 우점인 오유고립화를 공유한다고 하여도 그것 역시 자기의 난점을 가지고 
있다. 보다 명확하게 말하면 중요한 설계오유들이 통합단계에서 늦게 발견된다. 론리모둘 
들은 마지 막에 통합된 다. 때 문에 만일 어 떤 중요한 설 계 오유가 존재하면 그 오유는 그 
제 품의 많은 부분을 재 설계 하고 재 코드작성하는데 막대한 비 용을 소비 한 결과로 통합단 
계 의 마지 막에야 발견될 것 이 다. 

그러므로 하강식과 상승식설계 및 통합은 모두 자기의 우점과 약점을 가지고 있다. 
제 품개 발을 위한 해 결 방안은 우점 을 리 용하고 약점 은 최 소화하는 방식 으로써 두 전 략을 
결합하는것이다. 이것은 쎈드위치식실현 및 통합에 관한 착상을 가져 왔다. 

15. 1 . 3. 쌘드우 I 치식실현 및 ■합 

그림 15-2 에 보여 준 모둘호상접속도를 고찰하자. 6개의 모둘 a , b , c , d , g , j 듈욘 론 
리모둘이며 그러므로 이것들은 하강식으로 실현되고 통합되여야 한다. 7개의 모둘 e , f , h , 
i , k , 1, m 들은 조작모둘이며 그것들은 상승식으로 실현되고 통합되여야 한다. 즉 하강식 
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도 상승식도 모든 모둘에 적당하지는 않기때문에 해결방안은 그것들을 부분별로 가르는 
것이다. 6개의 론리모둘들은 하강식으로 실현되고 통합되며 중요한 모든 설계오유들은 
일찌기 발견될수 있다. 7개의 조작모둘들은 상승식으로 실현되고 통합된다. 결국 이 모둘 
들은 방어 적 으로 프로그람작성된 호출모둘들에 의하여 차폐 되 지 않으면서 어 떤 철저한 
시험을 받으며 그때문에 다른 제품들에 대한 확신과 더불어 재리용될수 있다. 모든 모둘 
들이 적당하게 통합되였을 때 두 모둘그룹사이의 대면부들이 하나씩 시험된다. 땐드위치 
식 실현 및 통합 implementation and integration ) 0 ] sfoL 부르는 이 과정 이 수행 되 
는 전 기간 오유고립화가 만족된다(다음의 《알고 싶은 문제》를 보시오.). 그림 15-3 은 
상승식 과 내 리 실현 및 통합뿐만아니 라 괜드위 치 식실현 및 통합의 우점 과 약점 을 종합하 
고 있다. 




[ | 론러모들 

■ 조작포둘 


—— 론려포둘과 조작모들을 결합하는 대면부 

그림 15-2. 쎈드위치식실현 및 통합을 리용하여 개발된 그림 15-1 의 제품 


알고 싶 e @제 

용어 팬드위 치식 실현 및 통합 (iaw/w/cA implementation and integration ) [Myers, ?79] 은 
론리모듈과 조작모듈을 쎈드위 치 의 웃부분과 아래 부분으로, 그것 들을 련결 하는 대 d 부를 
쎈드위치의 속으로 간주한데로부터 유래되였다. 이것을 그림 15-2 에서 볼수 있다. 
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연구방법 

우 점 

약 점 

실현후 통합 (15.1) 

- 

오유고립화가 실현되지 
않는다. 

기본설계오유들이 늦게 
로출된 다. 

내 리 실현과 
통합 (15.1.1) 

聲유고립화를 실현한다. 

기 본설 계오유는 일 찌 기 로출 
된 다. 

잠재적으로 재 리용가능 
한 모듈들이 충분히 시 
험되지 않는다. 

올리 실현과 
통합(15.1. 2 ) 

오유고립화를 실현한다. 

잠재적 으로 재 리용가능한 모 
둘들이 충분히 시험된다. 

기본설계오유들이 늦게 
로출된 다. 

쎈드위치식실현과 
통합 (15.1.3) 

유고립화를 실현한다. 
기본설계오유는 일찌기 로출 
된 다. 

잠재적 으로 재 리용가능한 모 
둘들이 충분히 시험된다. 

- 


그림 15-3. 실현 및 통합방법의 개괄과 서 술한 절 


쎈드위 치식실현 및 통합을 아래 의 란에 종합한다. 


쌘드위지식실현 및 를합을 진행하는 방법 

다음의 조작을 병렬로 진행한다. 

• 론리 모듈들을 하강식으로 실현하고 통합한다. 

• 조작모듈들을 상승식으로 실현하고 통합한다. 

다음조작을 진행한다. 

• 론리 모듈과 조작모듈사이 의 대 면부를 시 험한다. 


15. 1 . 4. 객체지향제품의 실현 및 틍합 

객체들은 상승식으로 또는 하강식으로 실현되고 통합된다. 만일 내 리실현 및 통합이 
선택된다면 대용체들은 고전적인 모둘들과 같은 방식으로 매개의 방법에 리용된다. 

만일 올리실현 및 통합이 리용된다면 다른 객체들에 통보를 보내지 않는 객체들이 
먼저 실현되고 통합된다. 그다음 이 객체들에 통보를 보내는 객체들이 실현되고 통합되 
는데 이 과정은 제품안의 모든 객체들이 실현되고 통합될 때까지 계속된다(이 과정은 재 
귀 가 존재 하는 경우에는 변경되여야 한다.). 

하강식과 올리실현 및 통합이 모두 지원되는것으로 하여 쎈드위치식실현 및 통합도 
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역시 리용될수 있다. 만일 제품이 C ++ 와 같은 혼성식객체지향언어 로 실현된다면 객체들 
은 흔히 고전적파라다임의 조작모둘들에 대응하며 이로부터 상승식으로 실현되고 통합된 
다. 객체들이 아닌 대부분의 모둘들은 론리모둘로 된다. 이 모둘들은 하강식으로 실현되 
고 통합된다. 다른 모둘들은 조작모둘로 되며 따라서 그것들은 상승식으로 실현되고 통 
합된다. 결국 모든 비객체모둘들은 객체들과 통합된다. 

제품이 Java 와 같은 순수한 객체지향언어를 리용하여 실현될 때에 조차도 main 과 같 
은 클라스방법 들(때 로는 정 적방법 me 功0쐬이 라고 부른다.)과 활용방법 들은 일 반적으 

로 구조화파라다임의 론리모둘들과 구조상 류사하다. 그러므로 클라스방법들 역시 하강 
식으로 실현되며 그다음 다른 객체들과 통합된다. 달리 말하면 하나의 객체지향제품을 
실현하고 통합할 때 쎈드위 치식실현 및 통합의 변종들이 리 용된다. 

15. 1 • 5. 실현 및 틍합단계에서의 관리문제 

관리와 관련한 한가지 문제는 통합할 때에 일부 모둘들이 단순하게 서로 결합되지 
않는다는것을 발견하는것이다. 실례로 프로그람작성자 1은 객체 01을 코드작성하고 프 
로그람작성 자 2는 객 체 o 2 를 코드작성한다고 하자. 프로그람작성 자 1이 리용하는 설 계 
문서에서는 객체 이이 객체 o 2 에 4개의 인수를 통해 어떤 통보를 보내지만 프로그람작 
성자 2가 리용하는 설계문서에서는 다만 3개의 인수만이 02에 보내진다는것을 명백히 
서 술하고 있다. 이 와 같은 문제 는 어 떤 변경 이 개 발그룹의 모든 성 원들에 게 통보되 지 
않고 설 계문서 의 하나의 복제본에 서만 만들어 지 는 경 우에 발생할수 있 다. 두 프로그 
람작성 자는 모두 자기 가 옳다고 생 각하며 서 로 타협하려 고 하지 않는다. 왜 냐하면 양 
보하는 프로그람작성 자는 그 제 품의 많은 부분을 재코드작성하여 야 하기 때 문이 다. 

이러한 문제들과 이와 류사한 불일치문제들을 해결하기 위하여서는 전체 통합과정을 
SQA 그롭이 실행하도록 하여야 한다. 더우기 다른 단계에서의 시험과 마찬가지로 SQA 그 
룹은 통합시험 이 부적당하게 진행된다면 큰 손실을 입게 된다. 그러므로 SQA 그룹은 시 
험이 철저히 진행되도록 할 가능성이 매우 크다. 때문에 SQA 그룹의 관리자는 통합단계 
의 모든 측면들에 대하여 책임을 져야 한다. 즉 관리자는 어느 모둘을 하강식으로 실현 
하고 통합하며 어 느 모둘은 상승식 으로 실현하고 통합하겠는가를 결정하여 야 하며 또 통 
합시 험 과제들을 적 당한 개 별적사람들에게 할당해 주어 야 한다. 쏘프트웨 어제품개 발계 획 
에서 통합시험계획을 작성하게 될 SQA 그룹은 그 계 획의 실현에 대 하여 책 임을 진다. 

통합단계의 마감에 모든 모둘들은 시험되여 단일한 제품으로 결합되게 된다. 

15. 2. 실현 및 통합단계에서의 시험 

여러가지 각이한 시험이 실현 및 통합단계에서 진행되여야 한다. 우선 새로운 
매개의 모둘은 그것이 이미 통합된 부분에 추가될 때 시험되여야 한다. 여기서 중요한 
점은 새로운 모둘을 제14장에서 서술한것처럼 시험하고 부분제품의 나머지부분들이 
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새 로운 모둘이 통합되 기 전과 마찬가지 로 계 속 동작한다는것 을 확인 하는것 이 다. 

제품이 도형사용자대면부를 가질 때에는 통합시험과 관련하여 특수한 문제점들이 
발생할수 있다. 이에 대하여 다음 절에서 론의한다. 

1 5. 3. 도형사용자대면부의 틍합시험 

어떤 제품을 시험하는것은 어떤 파일안의 어떤 시험실례에 대하여 입력자료들을 정 
렬함으로써 간단하게 될수 있다. 그다음 그 제품이 실행되고 련관된 자료들이 그에 따라 
실행된다. 비교적 초보적인 어떤 CASE 도구의 도움으로 전체 공정이 자동화될수 있다. 즉 
어떤 시험실례들의 모임이 매 실례의 예상되는 결과와 함께 작성된다. CASE 도구는 매 
시 험실례 들을 실행하여 실 지결과를 예 상되 는 결과와 비 교하며 사용자에 게 매 실례 에 대 
하여 보고한다. 그다음 시 험실례 들은 그 제품이 변경될 때 마다 진행하는 회 귀시험 에 리 
용하기 위하여 보관된다. SilkTest 는 이러한 도구의 한가지 실례로 된다. 

그러 나 어 떤 제 품이 어 떤 도형사용자대 면부를 병 합하는 경 우에 는 이 방법 을 적 용할 
수 없다. 특히 어떤 차림표를 내 리 펼치거 나 마우스로 찰칵하기 위한 시 험자료는 일반적 
인 시험자료와 같은 방식으로 파일안에 기억될수 없다. 동시에 GUI 를 수동적으로 시험하 
는것은 시간이 걸리고 지루한 작업이다. 이 문제에 대한 한가지 해결방안은 마우스찰칵, 
건반누르기 등과 같은 기능을 유지하는 어떤 특수한 CASE 도구를 리용하는것이다. GUI 
는 CASE 도구가 시 험파일 을 작성할수 있도록 일 단 수동적 으로 시 험된다. 그다음부터 이 
파일 은 그이 후의 자료들에 리 용된 다. QAPartner 와 XR _ er 를 비 롯한 여 러 가지 CASE 도구 
들이 GUI 의 시험을 지원하고 있다. 

통합과정이 완성될 때 제품전체가 시험된다. 이것을 제품시험 ( prac/wrt tesrtng ) 이라고 
부론다. 개발자들이 제품의 모든 측면의 정확성에 대하여 확신하게 될 때 그 제품은 인 
수시 험 testing ) 을 위 하여 의뢰자에게 넘겨 진 다. 이 두가지 류형의 시험을 보 

다 상세 히 론의 한다. 


1 5. 4. 제품시험 

마지막모둘들이 제품안에 성과적으로 통합되였다는 사실은 개발자들의 과제가 완성 
되 였 다는것 을 의 미하지 않는다. SQA 그룹은 여 전히 그 제 품이 성 공적 이 라는것 을 확정하 
기 위 한 여 러 가지 시 험 과제 를 수행하여 야 한다. 쏘프트웨어 에 는 두가지 기 본류형 즉 상 
업적인 규격 쏘프트웨어 ( C 0 TS )(2.1) 와 주문쏘프트웨어 (cw 次 om 새/ mwe ) 가 있 다. COTS 쏘프 
트웨어 를 개 발할 때 의 목적 은 그 제 품이 될수록 많은 구매 자들에 게 팔린 다는것 을 보증 
하는것 이 다. 그러 므로 COTS 쏘프트웨어의 모든 모둘들이 성 과적 으로 통합되 였을 때 제 
품은 제 품시 험 을 위하여 SQA 그룹에 넘 겨 진다. COTS 제 품시 험 의 목적 은 제 품전체 로서 
오유가 없다는것을 보증하는것이다. 제품시험이 완결될 때 그 제품은 2.6.1 에서 서술한 
바와 같이 알파시험과 베타시험을 거치게 된다. 즉 SQA 림이 스쳐 지나 간 제품의 잔류 
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오유와 관련한 의견을 받을 목적으로 제품의 초기판본을 선발된 장래의 제품구입자들에 
게 발송한다. 

한편 주문쏘프트웨어는 이와는 약간 다른 제품시험 을 거 치게 된다. SQA 그룹은 여 러 
가지 시 험 과제 를 수행하여 주문쏘프트웨 어 개발림 이 최 종적 으로 극복하여 야 할 장애 물로 
되는 인수시 험 에서 그 제 품이 실패하지 않는다는것을 확인한다. 인수시험 을 거 치게 될 
어떤 제품에서의 오유는 거의 언제나 개발기업체의 경영능력에 대한 나쁜 반영을 초래한 
다. 의 뢰 자는 개 발자들이 무능력 하다고 단정할수 있으며 이 로부터 의 뢰 자는 거 의 확정 적 
으로 이 개 발자들을 다시는 채용하지 않기 위하여 할수 있는 모든것을 다하게 된다. 더 
나쁘게 의뢰자는 개발자들이 불성실하고 계약을 빨리 결속하여 될수록 빨리 보수를 받으 
려 고 고의 적 으로 비 표준쏘프트웨어 를 넘 겨 주었 다고 믿 을수도 있 다. 만일 의 뢰 자가 진정 
이 렇게 생각하고 다른 잠정 적사용자들에게 말하게 되 면 개 발자들은 하나의 심각한 사회 
적비 난에 직 면 하게 된 다. 

SQA 그룹이 야말로 제품이 인수시험을 성공적으로 거친다는것을 확증할 의무가 있다. 
성공적인 인수시험을 담보하기 위하여 SQA 그를은 앞으로 하게 될 인수시험에 매우 
근사하다고 믿 어 지 는 시 험 방법 을 리용하여 제 품을 시 험하여 야 한다. 

1. 검 은통시험실례 들은 제 품전체 에 대 하여 실행 되 여 야 한다. 지 금까지 시 험실례 들은 
매 모둘 또는 객체들이 개별적으로 자기의 명세서들을 만족시킨다는것을 담보하 
면서 한 모둘씩 또는 한 객체씩 구성되 였다. 

2. 제 품전체 로서 의 로바스트성 이 시 험 되 여 야 한다. 게 다가 개 별 적 모둘들과 객 체 들의 
로바스트성은 통합과정 에 시험되였기때문에 이제는 제품전반의 로바스트성이 론 
점 으로 되 는데 바로 이 런 견지 에 서 시 험 들을 구성 하고 실 행하여 야 한다. 이 밖에 
제품은 강도시험(次 mu testing、”%: 받아야 한다. 즉 모든 말단들이 같은 시각에 등 
륵가입하려고 한다든가 또한 손님들이 모든 자동출납기들을 동시에 리용한다든 
가와 갈은 최대부하조건에서 제품을 조작할 때 그것 이 정확하게 동작한다는것을 
확인하여야 한다. 제품은 또한 용량시험 ( vo/wwe testing) 을 받아야 한다. 실례로 제 
품이 큰 입 력파일을 처 리할수 있다는것을 확인하여 야 한다. 

3. SQA 그룹은 제 품이 모든 제 약들을 만족시 킨다는것 을 검 열하여 야 한다. 실례 로 명 
세서 가 제품이 완전부하조건하에서 작업할 때 95%의 질문에 대 한 응답시 간이 3 s 
이하여야 한다는것을 서술하고 있다면 실제로 그렇게 된다는것을 검증하는것은 
SQA 그룹의 책임으로 된다. 의뢰자가 인수시험기간에 제약들을 검열한다는것은 
자명하다. 만일 제 품이 어 떤 중요한 제 약을 만족시키 지 못하게 되 면 개 발기 업 체 
는 상당한 신용을 잃게 될것이다. 이와 류사하게 기억에 관한 제약과 보안과 관 
련 한 제 약들이 검 열 되 여 야 한다. 

4. SQA 그롭은 모든 문서들이 코드와 함께 의뢰자에게 넘어 간다는것을 검토하여야 
한다. 또한 SQA 그룹은 문서 가 SPMP 에 규정 된 기 준에 맞는다는것 을 검 열하여 야 
한다. 이 밖에 문서는 제품에 대 치하여 시 험되 여 야 한다. 실례 로 SQA 그룹은 사용 
지 도서 가 그 제 품을 리 용하기 위한 정 확한 방법 들을 실지 로 반영 하고 있으며 제 
품의 기 능들이 사용지도서 에 명 시 된것 과 같다는것 을 결정하여 야 한다. 
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객체지향쏘프트웨어의 제품시 험 에서 대 본들 (12.4) 이 쓸모 있을수 있다. 제 품의 거동 
이 명백 히 규정된것과 같다는것을 보증하기 위하여 제품은 전체 로서 매 개의 대 본에 기 초 
하여 자세 히 검 토된 다. 대 본검 열 은 개 별 적 인 모둘과 객 체 들의 검 토는 물론 설 계 검 토과정 
에도 유용하다. 그러나 대부분의 대본들 특히는 결정적인 대본들은 모둘과 객체의 경계 
에 놓이 므로 제 품시 험 기간에 만 대 본검 열 을 하는것 이 가장 완전 한 능력 을 발휘할수 있게 
한다. 

일 단 SQA 그룹이 관리 자측에 게 제 품이 인수시 험 자들이 제 시하는 그 어 떤 문제 들도 
처 리할수 있다는것 을 보증하면 그 제 품(즉 코드와 모든 명세 서 들)은 인수시 험 를 위하여 
의뢰자측에 넘겨 진다. 


1 5. 5. 인수시험 

인수시험의 목적은 의뢰자가 그 제품이 개발자들이 주장하는것처럼 명세서들을 실지 
로 만족시키는가를 결정하도록 하는것이다. 인수시험은 의뢰자측 또는 의뢰자측 대표자 
들의 면전에 있는 SQA 그룹 또는 이 목적 을 위하여 의 뢰 자들이 채 용한 독립 적 인 SQA 그 
룹에 의하여 진행된다. 인수시 험 은 자연히 정 확성시험 을 포함하지 만 이 밖에도 성 능과 로 
바스트성 을 시 험하는것 이 필 요하다. 인 수시 험 의 네 가지 중요한 요소는 정 확성 , 로마스트 
성，성능 및 문서의 시험 인데 이것들은 명백히 개 발자들이 제품시험기간에 진행하는 시 
험들이다. 제품시험은 인수시험을 위한 하나의 종합적인 시연회이기때문에 여기에 놀랄 
필 요는 없 다. 

인 수시 험 의 한가지 중요한 측면은 그것 이 시 험자료가 아니 라 실 지자료에 기 초하여 
수행 되 여 야 한다는것 이 다. 시 험실례 들이 아무리 잘 작성 되 고 자연스럽 다고 하여 도 그것 
들은 인공적 인것 이 다. 더 중요하게 는 시 험자료가 대 응하는 실 지자료의 어 떤 진실 한 반영 
으로 되여 야 하지만 실천적으로는 늘 그렇게 되지는 않는다. 실례 로 실지자료를 특징 짓 
는데 책임이 있는 명세작성림의 성원들은 이 과제를 부정확하게 수행 할수도 있다.반대로 
비 록 자료는 정 확하게 명 시된다고 하여 도 그 자료명세서 를 리용하는 SQA 그룹성 원 이 그 
것 을 오해할수도 있다. 그 결과로 생성 된 시 험 실례 들은 실 지자료에 대 한 진실한 반영으 
로 되지 못하며 부적 당하게 시 험된 어떤 제품을 초래하게 된다. 

이러한 리유들로 하여 인수시험은 실지자료에 대하여 진행되여야 한다. 더우기 개발 
림 은 제 품시 험 이 인수시 험 의 모든 측면들을 중복할것 이 라는것 을 담보하려 고 노력 하기 때 
문에 제 품시 험 도 역 시 될 수록 실 지자료에 대 하여 수행 되 여 야 한다. 

어떤 새 제품이 현존제품을 대신하게 될 때 명세서에는 거의 언제나 그 새 제품이 현 
존제품과 병렬로 실행되도록 설치되여야 한다는 취지의 조항을 포함한다. 그 리유는 새 
제 품이 어떤 방식 으로든 실패할수 있는 실제 적가능성 이 존재 하기때 문이 다. 현존 제품은 정 
확하게 동작하지만 일부 측면에서 부적 당하다. 만일 현존 제품이 부정확하게 동작하는 어 
떤 새 제품으로 교체된다면 의뢰자는 난관에 봉착하게 된다. 그러므로 의뢰자가 새 제품 
이 현존하는 제품의 기능들은 대 신할수 있다는것을 인정할 때까지는 두 제품이 병 렬로 실 
행되 여 야 한다. 병 렬실행 이 성 공하면 인수시험 을 결속하고 현존제품을 폐 기할수 있다. 
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제품이 인수시험을 거쳤을 때 개발자의 과제가 완수된다. 이제 그 제품에 가해 지는 
임의의 변경들은 유지정비를 위하여 진행될 따름이다. 

15. 6. 실현 및 틍합단계에서의 CASE 도구 

실현을 지 원하기 위한 CASE 도구들은 제5장에서 약간 자세 히 서술하였 다. 실현 및 통 
합단계 의 통합요소들을 위하여 관본조종도구, 구축도구, 구성 관리 도구들이 요구된다 (5 장). 
그 리유는 시험되고 있는 모둘들은 오유들이 발견되고 정정됨에 따라서 끊임없이 변경되 
며 이러한 CASE 도구들은 매 모둘의 적당한 판본들이 콤파일되고 링크된다는것을 담보하 
는데서 필수적인것으로 되기때문이다. 앞에서도 언급한바와 같이 세가지 중요한 UNIX 판 
본조종도구들은 sees (source code control system ; 원천코드조종체 계) [ Rochkind , 1975], 
rcs(revision control system; 개 정 판조종체계) [ Tichy , 1985], evs {concurrent versions system', 
병 행 판본체 계 ) [Loukides and Oram , 199 刀 이 다. 시 장에 서 구입 할수 있는 구성 조종작업 프로 
그람으로서는 PVCS 와 SourceSafe 를 들수 있다. 

지 금까지 매 장마다 그 단계 에 특정한 CASE 도구들과 작업 대들을 서술하였다. 이제는 
개 발공정 의 모든 단계 가 서 술되 였 으며 제 품전체 를 위한 CASE 도구를 고찰할 차례 이 다. 

15.7. 완전한 쏘프트웨어공정에서의 CASE 도구 

CASE 내 에 는 자연스러 운 진보과정 이 존재한다. 5.6 에 서 설 명한것 처 럼 가장 단순한 
CASE 수단은 직결식 대 면부검 사기 interface checker) 또는 구축도구 too /) 와 같 
은 단일도구이다. 다음으로 도구들이 결합되여 구성조종 또는 코드작성과 같은 쏘프트웨 
어개 발공정 에서의 하나 또는 두개 의 활동을 지 원하는 작업 대(씨0삯뇨«새)가 만들어 졌다. 
그러나 전체에 대하여서는 말할것도 없고 그것이 리용될수 있는 쏘프트웨어개발공정의 
제한된 범위에서조차 경영진에게 정보를 제공하지 못할수 있다. 결국 개발환경 
( env / rawne 때)이 비록 전부는 아니 라 해도 대부분의 개발공정에 대하여 콤퓨터에 의한 지 
원을 제공하여 준다. 

리 상적 으로 매 쏘프트웨 어개 발기 업 체 들은 개 발환경 을 리용하여 야 한다. 그러 나 어 떤 
개 발환경의 비 용은 방대할수 있 다. 즉 프로그람묶음 그자체 뿐만아니 라 그것 을 실행할 하 
드웨어 에 많은 비용이 든다. 보다 작은 개 발기 업체 에는 작업 대든가 또는 도구들의 모임 이 
적 당할수 있 다. 그러 나 가능하다면 개 발과 유지 정 비 노력 을 지 원 하기 위하여 어 떤 통합화 
된 개발환경을 리용하여 야 한다. 

1 5. 8. 통합화된 개발환경 

CASE 와 관련한 범위내 에서 단어《통합화된》의 가장 공통적 인 의미는 사용자대 면부 
통합 ( w〜r interface Wegra 致써)이 라는 용어 에 있다. 즉 그 환경 안의 모든 도구들이 하나의 
공통적인 사용자대면부를 공유한다. 이 리면에 있는 착상은 모든 도구들이 갈은 시각적 
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외형을 가진다면 한개 도구를 다룰수 있는 사용자는 그 환경안의 다른 도구를 배우고 리 
용할 때 어려움이 적어야 한다는것이다. 이 착상은 마킨토쉬에서 성공적으로 실현되였는 
데 여기에서는 대다수의 응용들이 류사한《보기와 느낌》을 가지고 있다. 비록 이것이 
일반적 인 의미 라고 하여도 다른 류형의 통합도 있다. 

용어 도구통합 ( too / integration ) 은 모든 도구들이 같은 자료형식을 통하여 통신한다는 
것을 의미하고 있다. 실례로 UNIX Programmer's Workbench 에서 UNIX pipe 형식은 모든 
자료들이 하나의 ASCII 흐름형식으로 존재한다는것을 가정하고 있다. 결국 한 도구에서 
나오는 출력 을 다른 도구의 입 력흐름에 지 향시 킴 으로써 두개 의 도구를 쉽 게 결 합한다. 

공정 통합(戶 racew integration ) 은 하나의 특정 한 쏘프트웨 어개 발공정을 지 원하는 어떤 환 
경을 가리 킨 다. 이러한 부류의 환경들의 하나의 부분모임이 기법에 기초한 환경 ( technique - 
based 이다(다음의 《알고 싶은 문제》를 보시오.). 이러한 류형의 환경은 완전 

한 공정 이 아니 라 쏘프트웨어를 개 발하는 어떤 특정 한 기 법 만을 지 원한다. 이 책 에서 론의 
된 여 러 가지 기법 들 즉 게인과 사르센의 구조화체 계 분석 (11.3), 잭 슨체 계 개 발(13.5)，페 트리 망 
(11.7) 들을 위 한 환경 들이 존재 한다. 이 러 한 환경 들의 대 다수는 명세 작성 과 설계 단계 를 위 한 
도형적지 원을 제 공하며 자료사전을 병 합한다. 일부 일치성 검 열 들은 일반적 으로 지 원된다. 
개 발공정 을 관리 하기 위한 지원이 환경 에 병 합된다. Analyst / Designer 와 Rhapsody 를 비 롯하 
여 이러한류형의 환경들은 대부분 시장에서 구입할수 있다. Analyst/Designer 는 상태도표 
( Stotec 加 r /) 를 지원한다 [Harel et al „ 1990]. 객체지향방법들과 관련하여 Rose 는 통합쏘프 
트웨 어 개 발공정을 지원한다 [ Jacobson , Booch and Rumbaugh , 1999]. 이 밖에 일부 낡은 환 
경들이 객체지향파라다임을 지원하도록 확장되였다. Software through Pictures 가 이러한 
류형의 한가지 실례 이 다. 거의 모든 객체지향환경은 UML 을 지 원하고 있다. 


알고 싶 e @제 

문헌들에서 기법에 기초한 환경 (technique-based envimnmenf ) 을 보통 방법에 기: ; 한 환 
정 {method-based /?rogra/ww_«g) 이 라고 부른다. 객체지 향파라다임의 출현은 단어 방법 
(we 泊 o 句에 또 하나의 의 미를 주었다 (쏘프 트웨 어공학의 범위내 에서). 그것의 원래』 의 미 
중、기법 (tec/w/ 우 we) 또는 방법 (« 公 proacA) 이다. 이것이 이 단어가 방법에 기초호 환경 
{method-based e « v / rawne «<) 에 리 용된 근거 이 다. 이 단어 의 객 체 지 향적 의 ᄆ):울 7.7 에， 설명 
한것처럼 어떤 객체 또는 믈라스안의 작용이다. 유감스럽게도 때때로 어느 의미가 사적되 
는가는 문맥상 전혀 명백치 않다. 

따라서 이 책 에서는 객 체지향파라다임의 범위내 에서 만 단어 방법 (we 태 o«0 을 리 卜한다. 
한편 용어 기법 (tec/w 句 Me) 또는 방법 (a 公 proac/;) 을 리용한다. 실례로 이것은 제11장": 서 용 
어 형식적 방법 (/bma/ we 泊 o 句이 나타나지 않는 리 유이 다. 그대신 이 책에서는 형식적기법 
{formal technique、) 을 리용한다. 이와 류사하게 이 장에서 용어 기법에 기초考 환경 
itechnique-based environment) 을 리용한 다. 


대부분의 기법에 기초한 환경들에서 쏘프트웨어개발에서의 수동적인 조작을 지원하 
고 형식화하는데 중점을 두고 있다. 즉 이러한 환경들은 사용자로 하여금 저자가 지적한 
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방식으로 기법들을 계단식으로 리용할수 있게 하며 한편 도형도구，자료사전, 일치성검열 
들을 제공함으로써 사용자들을 지원한다. 이러한 콤퓨터화된 틀은 기법에 기초한 환경의 
우점이며 여기서 사용자들은 특정한 기법들을 리용하여 그것을 정확하게 리용하게 된다. 
그러나 그것은 약점으로 될수 있다. 개발기업체의 쏘프트웨어개발공정이 이러한 특정한 
기법들을 병합하지 않는한 기법에 기초한 환경의 리용은 비생산성을 초래할수 있다. 

15.9. 업무응용들 위한 개발환경 

한가지 중요한 부류의 개발환경이 업무지향제품을 구성하는데 리용된다. 여기서 중 
요한 점은 리용하기 쉬우며 여러가지 방식으로 실현된다는것이다. 특히 이 환경은 여러 
가지 표준화면들을 병 합하고 있는데 이 화면들은 사용자지향 GUI 발생 기 를 통하여 끝없 
이 변경 될 수 있 다. 이 와 같은 개 발환경 에 서 한가지 보편적 인 특성 은 코드발생 기 이다. 그 
로부터 상세설계가 가장 낮은 준위의 제품추상화로 된다. 상세설계는 C , C ++ 또는 Java 
와 같은 언어 로 코드를 자동적 으로 발생하는 코드발생 기 의 입 력 으로 된다. 자동적 으로 
발생된 이 코드가 를파일된다. 즉 그우에서 객체지향환경들이 현재 UML 을 지원하고 있 
다. 대다수의 기법에 기초한 환경에서 중점은 아무런 종류의 《프로그람작성》도 진행되 
지 않는다는것 이 다. 

상세설계 를 명 시 하기 위한 언어 가 미 래의 프로그람작성언어 로 될것 이 다. 프로그람작 
성언어들의 추상준위는 1세대 및 2세대언어의 물리적기계준위로부터 3세대 및 4세대언어 
의 추상기계준위로 올라 간다. 현재 상세설계준위，이식가능한 준위가 이러한 류형의 환 
경 들의 추상준위 로 된다. 14.2 에서 는 4세 대언어 를 리용하는 목적 은 원천코드길 이 를 더 짧 
게, 개 발을 더빨리 하며 유지정 비를 더 쉽 게 하는것 이 라는것을 설명하였다. 코드발생 기의 
리용은 프로그람작성자가 4 GL 을 위한 콤파일러나 해석기보다 코드발생기에서 보다 적은 
세부를 진행하게 된다는 점에서 이러한 목적을 훨씬 더 달성할수 있게 한다. 결국 코드 
발생 기 를 지 원하는 업 무지향환경 의 리용은 생 산성 을 중대 시킬것 으로 예 상된다. 

Foundation 과 Bachman Product Set 를 비롯한 이러한 류형의 여러가지 환경들은 현재 
구입할수 있다. 업무지향 CASE 환경에 대한 시장규모를 고려하면 앞으로 이러한 류형의 
개발환경들이 더 많이 개발될것 같다. 

15. 10 . 공용도구의 하부구조 

정 보기 술연구를 위 한 유럽 전략계 획(표 " rope strategic Programme for Research in 
Information Technology ; ESPIT ) 은 CASE 도구를 지 원하기 위 한 하나의 하부구조를 개 발하 
였 다. 그 이 름파는 달리 이 식 가능한 공용도구환경 ( por 切 We common tool environment ; 
PCTE ) [ Thomas , 1989, and Long and Morris , 1993] 은 개발환경이 아니다. 그대신 이것은 
UNIX 가 사용자제품에 필요한 연산체계봉사를 제공하는것과 같은 방식으로 CASE 도구에 필 
요한 봉사를 제공하여 주는 하나의 하부구조이다 ( PCTE 에서 단어 《 common 》 은 《 public 》 
또는 《not copyrighted 》 의 의미로 쓰인다.). 
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PCTE 는 광범 히 응용되 였 다. 실례 로 PCTE 와 PCTE 에 대 한 C 와 Ada 대 면부들은 1995 
년에 ISO / IEC 규격 13기9로서 도입 되였다. PCTE 의 실현들은 Emeraude 와 IBM 의 실현들을 
포함하고 있다. 

앞으로 더욱더 많은 CASE 도구들이 PCTE 규격 을 승인하게 될것 이며 PCTE 그자체가 
보다 광범한 종류의 콤퓨터 상에 서 실현될것 으로 기 대된다. PCTE 를 승인하는 도구는 
PCTE 를 지원하는 임의의 콤퓨터상에서 실행될것이다. 따라서 이것은 CASE 도구들의 많 
冬 부분들이 광범히 응용되게 하여 야 하며 이것은 보다 좋은 쏘프트웨 어개 발공정과 모든 
질 좋은 쏘프트웨어 를 개 발하는데 로 이 어 져 야 한다. 

15. 11. 개발환경에서 제기될수 있는 문제 

모든 제품들과 모든 개발기업체들에 리상적인 개발환경이란 없으며 하나이상의 프로 
그람작성언어가《가장 좋다.》고 간주될수 있다. 이 개발환경들은 자기의 우점과 약점을 
가지고 있으며 어떤 부적당한 개발환경을 선택하는것은 개발환경을 전혀 리용하지 않는것 
보다 못할수 있다. 실례로 15.8 에서 설명한바와 같이 어떤 기법에 기초한 개발환경은 사실 
상 어떤 수동적 인 과정을 자동화한다. 만일 어떤 개 발기 업체 가 그 개 발기 업 체전체 에 또는 
개 발되고 있는 현재의 쏘프트웨 어제품에 부적 당한 기 법을 강요하는 어떤 개 발환경을 리용 
하도록 선택 한다면 그러 한 CASE 환경 의 리 용은 비 생 산성 을 초래 하게 될 것 이 다. 

보다 나른 정황은 어떤 개발기업체가 5.10 의 권고 즉 CASE 환경의 리용은 개발기업 
체 가 CMM 준위 3에 도달할 때 까지 피 하여 야 한다는것 (2.11) 을 무시 하고 선택하는 경 우에 
발생한다. 물론 매개의 개발기업체는 CASE 도구를 리용하여야 하지만 일반적으로 작업대 
를 리용할 때 손해 가 적 다. 그러 나 개 발환경 은 그것 을 리용하는 어 떤 개 발기 업 체 들에 게 
자동화된 쏘프트웨 어개 발공정 을 강요한다. 만일 좋은 개 발공정 을 리용한다면 즉 개 발기 
업체 가 3준위 또는 그보다 높은 준위 에 있다면 그 개 발환경의 리용은 공정 을 자동화함으 
로써 쏘프트웨어생산의 모든 측면을 도와 주게 될것이다. 그러나 만일 개발기업체가 위 
험구동준위 1이든가 지어 2준위에 있다면 이와 같은 공정은 그 어디에도 없다. 이러한 
실제하지 않는 공정 을 지 동화하는것 즉 CASE 개 발환경 ( CASE 도구나 CASE 작업 대 에 대 립 
하는것 으로서)의 도입 은 혼란만을 초래할수 있 다. 

15. 1 2. 실현 및 통합단계에서의 척도 

코드행과 맥케브의 주기적복잡도를 비롯하여 실현 및 통합단계에서의 여러가지 각이 
한 복잡도에 관한 척도들이 14.8.2 에서 론의되 였 다. 시험의 관점 으로부터 그와 련관된 척 
도들에 는 시 험실례의 총 개 수와 오유를 초래하는 시 험실례 의 개 수가 포함된다. 일 반적 인 
오유통계 를 코드시 험 을 위하여 유지 하여 야 한다. 오유의 총 개 수도 중요하다. 왜 냐하면 
어떤 모둘이 나 객체 에 서 발견된 오유의 개수가 사전에 결정한 어떤 최 대 값을 초과하면 
14. 14에서 론의한바와 같이 그 모둘이 나 객체는 다시 설계 하고 다시 코드작성해 야 하기 
때문이다. 이밖에 발견된 오유의 류형과 관련하여 세부적통계들을 보관해 둘 필요가 있 
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다. 전형적인 오유류형들에는 설계에 대한 오해，초기화의 결여, 변수리용에서의 불일치 
성이 포함된다. 오유자료들은 시험목록들에 병합되여 장래의 제품에 대한 코드시험기간 
에 리용되게 된다. 


15. 13. 항공음식전문회사 실례연구: 

실현 및 틍합단계 

항공음식 전문회 사제 품에 대 한 C ++ 와 Java 에 의한 완전한 실현은 www . mhhe.com 
/ engcs / compsci / schach 로부터 내려 받을수 있다. 이 실현은 상세설계(부록 8과 부록 9) 의 
코드에 로의 직접번역 으로 간주할수 있다. 즉 설계 자들은 프로그람작성 림 에게 순전히 C ++ 
또는 Java 로 실현하도록 요구하는 심사숙고한 한가지 설계를 제출하였다. 프로그람작성자 
들은 여 기서 유지정 비를 하는 프로그람작성 자들을 돕기 위하여 설명 문을 포함하였 다. 이 
실현은 문제 14.21 부터 14.25 까지의 된통시험실례들은 물론 부록 10의 검은통시험실례들 
에 대하여 시험되였다. 

15. 1 4. 실현 및 통합단계에서의 난관 

순수한 기술적관점으로부터 보면 실현 및 통합단계는 상대적으로 간단하다. 만일 요 
구사항확정，명세작성(분석)，설계단계들이 만족스럽게 수행되면 실현 및 통합의 과제들 
은 유능한 프로그람작성자들에게 적은 문제점을 제출하여야 한다. 그러나 실현 및 통합 
단계의 관리는 매우 중요하다. 실현 및 통합단계에서의 난관은 이 분야에서 발생한다. 

적 당한 CASE 도구들의 리용(15.11)，일 단 명세서 가 의뢰 자들에 의하여 수표된 시험계 
획 (9.8 .句, 설계에 대한 변경이 모든 련관된 사람들에게 전달된다는것을 담보하는것(15.15)， 
시험을 중지하고 제품을 의뢰자에게 배포할 시기를 결정하는것 (6 丄 2) 들이 제품의 성패와 
관련된 대표적인 론점들이다. 

쏘프트웨 어개 발공정 의 효과적 인 관리 는 효과적 인 쏘프트웨 어 생 산에 서 본질 적 인 문제 
이 다. 즉 이것은 능력 성 숙도모형 (2.11) 과 같이 쏘프트웨 어개 발공정 을 개 선하기 위한 노력 
을 유발시키 게 된 다. 그러 나 이 절의 첫 부분에 서 서 술한바와 같이 관리 는 실현 및 통합 
단계에서 특별히 중요한 문제로 제기된다. 

요 약 

실현 및 통합활동들은 병렬로 진행되여야 한다 (15.1). 하강식, 상승식，쎈드위치식실 
현 및 통합이 서술되 고 서 로 비 교된다 (15 丄1부터 15丄3까지). 객체지향제품의 실현 및 통 
합은 15丄4에 서 론의 된 다. 제 품시 험 (15.4) 과 인수시 험 (15.5) 을 비 롯한 각이한 류형 의 시 험 
이 실 현 및 통합단계 에 서 수행 되 여 야 한다 (15.2). 도형사용자대 면부의 통합시 험 에 의하여 
특수한 문제들이 제기될수 있다 (15.3). 15.6 에서는 실현 및 통합단계에서의 CASE 도구들에 
대 하여 론의한다. 완전한 개 발공정 에서의 CASE 도구들은 15.7 절에서 론의된다. 통합화된 
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CASE 도구들에 대한 문제는 15.7 에서 론의된다. 15.10 은 공용도구의 하부구조에 대하여 
주목을 돌리 고 있 다. 다음으로 개 발환경 과 관련된 잠재 적문제 들이 론의 되 며 (15.11) 실현 
및 통합단계에서의 척도들이 론의된다 (15.12). 이 장은 항공음식전문회사제품의 실례연구 
에 대한 실현 및 통합 (15.13) 과 실현 및 통합단계에서의 난관에 대한 론의 (15.14) 로써 결 
속된다. 


보 충 

통합시 험를 위한 시험자료의 선택은 문헌 [Harrold and Soffa , 1991] 에 제시되 였다. 문 
헌 [ Munoz , 1988] 은 제품시험에 대한 한가지 방법을 서술하고 있 다. 어떤 제품시험을 계 
속하는데 얼마동안 높은 비 용효률을 유지하겠는가를 파악하는것 이 중요하다. 이 문제 에 
대 한 해 결방안은 문헌 [ Brettschneider , 1989, and Sherer , 1991] 에 서술되 였 다. 대 규모제품의 
시험은 문헌 [House and Newman , 1989] 에 서술되였다. 

Software through Pictures [Wasserman and Pircher , 198 刀을 비롯한 여러가지 기법에 기 
초한 개 발환경 들이 존재한다. 통합화된 CASE 도구들에 대 한 정 보는 IEEE Software 1992년 
3월호에서 특히 문헌 [Brown and McDermid , 1992, and Chen and Norman , 1992] 에서 찾아 
볼수 있다. 

2년 또는 3년마다 ACM SIGSOFT 와 SIGPLAN 은 Symposium on Practical Software 
Development Environments 를 발행 한다. 이 회 보는 도구모임 과 개 발환경 에 대 한 넓 은 범 위 
의 정보를 제공하여 준다. 또한 the annual International Workshops on Computer Aided 
Software Engineering 에 대 한 회 보도 쓸모 있 다. 개 발환경 에 대 한 그이 상의 론문들은 IEEE 
Software 1992년 5월 호를 비 롯한 각이한 잡지 들의 전문주제 들에 서 찾아 볼수 있 다. 

객체지향파라다임과 관련하여 문헌 [Jorgensen and Erickson , 1994] 는 객체지향쏘프트 
웨어에 대한 통합시험 을 서술하고 있다. Communications of the ACM 1994 년 9 월호는 객 
체지향쏘프트웨어의 시험 에 대 한 여 러개의 론문을 포함하고 있다. 

PCTE 에 대한 개요는 문헌 [ Thomas , 1989] 에서 찾아 볼수 있다. 문헌 [Long and 
Morris , 1993] 은 PCTE 에 대한 많은 정보자원을 포함하고 있다. 

문 제 

15.1. 론리 모둘과 조작모둘의 차이 를 설 명 하시 오. 

15.2. 방어프로그람작성은 좋은 쏘프트웨어공학실천으로 된다. 동시에 그것은 조작모 
둘이 재리용목적에 충분하도록 철저히 시험되는것을 가로 막는다. 이러한 명백한 모순은 
어떻게 해결할수 있는가? 

15.3. 제 품시 험 과 인수시 험 의 류사성 은 무엇 인가? 기 본차이 는 무엇 인가? 

15.4. SQA 그룹이 실천 및 통합단계 에서 노는 역 할은 무엇 인가? 

15.5. 당신은 1인쏘프트웨어회사의 주인이고 유일한 직원이다. 당신은 경쟁을 위하여 
CASE 도구를 사야 한다고 결심한다. 그러 므로 당신은 15,000딸라의 은행 대 부를 요청한다. 
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은행 경 영자는 당신에 게 왜 CASE 도구를 필 요로 하는가를 일 반용어 로 설 명하는 1 페 지 를 
넘지 않는(더 짧으면 좋다.) 설명문을 요구한다. 그 설명문을 작성하시오. 

15.6. Ye Olde Fashioned Software Corporation 회 사의 쏘프트웨 어 개 발부의 새 로 임 명 된 
부책 임 자는 회 사가 쏘프트웨어 를 개 발하는 방식 을 변경하는데 서 방조를 받을 목적 으로 
당신을 채용하였다. 회사에는 650 명의 직원이 있으며 그들은 모두 아무런 CASE 도구의 
도움도 없 이 COBOL 코드를 작성 하고 있 다. 회 사가 어 떤 종류의 CASE 도구를 구입하여 야 
하는가를 설명하는 부책 임 자에 게 내 는 비 망록을 작성 하시 오. 당신의 선택 을 주의 깊게 증 
명 하시 오. 

15.7. 당신과 한 동료가 Personal Computer Software Programs Are Us 에 착수하여 개 인 
콤퓨터 상에 서 개 인콤퓨터 용쏘프트웨 어 를 개 발하기 로 결심 하였 다. 그리 고 먼 친척 이 죽으 
면서 당신이 그 돈을 업 무지향개 발환경 과 그것 을 실 행하는데 필요한 하드웨 어 를 구입하 
고 그 개발환경을 적어도 5 년간 유지하는데 소비한다는 조건하에서 당신에게 백만딸라의 
자금을 넘겨 주었다. 당신은 무엇을 해 야 하며 왜 그렇게 해 야 하는가? 

15.8. 당신은 어 떤 우수한 소규모문예단과대 학의 를퓨터 과학교수이 다. 콤퓨터 과학과 
정 안을 위한 과목 함 량이 35 개 의 개 인콤퓨터 를 망라한 망우에 서 실 현된 다. 학장이 어 떤 
종류의 싸이트리 용허 가가 허 락되 지 않는 한 매 CASE 도구의 복제본을 구입해 야 한다는것 
을 념두에 두면서 당신에 게 제 한된 쏘프트웨 어예 산을 리 용하여 CASE 도구들을 사겠는가 
말겠는가를 묻는다. 당신은 이때 무엇을 권고하겠는가? 

15.9. 당신은 어 떤 중요한 도시 의 시 장으로 금방 선거되 였 다. 도시 를 위한 쏘프트웨 
어 를 개 발하는데 그 어 떤 CASE 도구들도 리용되 지 않고 있 다는것 을 당신은 발견하였 다. 
당신은 무엇을 하겠는가? 

15.10. (과정안상 목표) 브로드렌 즈지역 아동병 원제 품(부록 1) 을 실 현 하고 통합하시 오. 
교원이 지정하는 프로그람작성언어를 리 용하시 오 . 교원이 당신에게 web 에 기초한 사용자 
대 면부든가 도형 사용자대 면부든가 본문에 기 초한 사용자대 면부를 구성 한다고 말할것 이 다. 
당신이 작성한 코드를 시 험 하기 위하여 문제 14.20 에 서 개 발한 검 은통시험 실례 들을 리용 
하는것 을 기 억하시 오. 

15.11. (실례연구) 13. 13 의 상세설계 로 출발하여 C++ 또는 Java 가 아닌 객체지향언어 
로 항공음식 전문회 사제 품의 실례연구를 코드작성 하시 오. 

15.12. (실 례연구) C++ 특성 이 없는 순수한 C 토서 항공음식 전문회 사제 품의 실 례연구 
(15.13) 를 재작성 하시 오. 비 록 C 가 계 승을 지 원하지 않을지 라도 교갑화와 정 보은폐 와 같 
은 객체에 기초한 개념들이 쉽게 달성될수 있다. 다형성과 동적결합을 어떻게 실현하겠 
는가? 

15.13. (실례연구) 15.13 의 실현에 대 한 코드문서 가 어느 정 도로 부적 당한가? 임의의 
필요한 보충을 하시오. 

15.14. (쏘프 트웨 어 공학독본) 교원 은 문헌 [Jorgensen and Erickson, 1994] 의 복제 본을 
배 포할것 이 다. 객체지향통합과 고전적 통합의 기 본차이는 무엇 인가? 
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제 1 6장. 유지정비단계 


제품이 일단 인수시험을 거치게 되면 그것은 의뢰자에게 넘어 간다. 제품은 설치되 
여 그것을 만들 목적에 리용되게 된다. 그러나 모든 유용한 제품들은 거의 확정적으로 
유지정비단계에서 유지정비를 거치게 되며 오유를 수정하거나(교정유지정비) 또는 제품 
의 기능을 확장(확대)하게 된다. 

제품은 원천 코드만으로 구성되지 않기때문에 제품이 의뢰자에게 넘어 간 다음에 그 
제품의 문서，지도서나 기타 요소들에 가해 지는 모든 변경들은 다 유지정비의 실례로 
된다. 일부 콤퓨터과학자들은 제품이 시간에 따라 진화된다는것을 지적하기 위하여 유지 
정 비 라는 용어보다 진화 ( evo / wft ’ on ) 라는 용어 를 더 즐겨 쓴다. 사실 일부 사람들은 전체 
쏘프트웨 어생명주기의 시 작부터 끝까지를 하나의 진화과정 으로서 간주한다. 

이 책의 한가지 기본주제는 유지정비의 사활적인 중요성에 대한 문제이다. 그러므로 
이 장이 상대 적 으로 짧은데 대 하여 놀 랄수도 있 다. 그 리유는 유지 정 비 성 이 제 품개 발공 
정의 첫 시기부터 제품에 구현되여야 하며 개발공정의 그 어느 시기에도 양보하지 말아 
야 하는 문제 이기때 문이 다. 그렇기때문에 실제적 인 의미 로 보면 선행한 모든 장들에서 
유지 정 비 라는 주제 에 품을 들여 왔다. 이 장에 서 는 유지 정 비 성 이 유지 정 비단계 그자체 에 
서 양보되지 않는다는것을 어떻게 담보하겠는가에 대하여 서술한다. 

1 6. 1 . 유지정비의 필요성 

제품에 대하여 변경을 가하여야 할 세가지 기본 리유가 있다. 

O 첫번째 리 유는 오유들 즉 명세 서오유, 설계오유, 코드작성오유，문서 작성오유 또는 
기 타 류형 의 오유들을 정 정 하는것 이 다. 이 것 을 교정 유지 정 비 (corrective maintenance ) 
라고 부론다. 놀랍게 도 65개 개 발기 업 체 들에 대 한 하나의 연구자료는 유지 정비 프 
로그람작성 자들이 교정유지 정 비 에 자기 들에 게 부여 된 시 간의 17.5%만을 소비한 
다는것을 보여 주었다 [ Lientz ， Swanson , and Tompkins , 1978]. 이것은 그림 16_1의 
파라다임도표에서 보여 주고 있다. 



□ 정확성 ■완전성 ■적응성 □기타 

그림 16-1. 매 류형의 유지정비에 드는 시간의 퍼센트 
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V 유지정비프로그람작성자들은 대부분의 소여시간 즉 60.5%의 시간은 두번째 류형 
의 유지정비 즉 완전유지정비切巧浴 cAVe maintenance )^ 소비하였다. 여기에서는 제품 
의 효률성을 개선할 목적으로 코드에 대한 변경이 진행되였다. 실례로 의뢰자는 보 
충적인 기능을 추가하거 나 제품이 더빨리 실행되도록 그 제품이 변경되기를 바랄 
수 있다. 어떤 제품의 유지정비성을 개선하는것은 완전유지정비의 또 한가지 실례 
로 된다. 

■fe 제 품을 변경 시 켜 야 할 세 번째 리 유는 적 응유지 정 비 ( acfojyft've maintenance ) ^1 이 
때에는 제품이 동작하는 환경에서의 변화에 그 제품이 적응하도록 변경이 가해 
진다. 실례로 어떤 제품은 새로운 콤파일이나 조작체계，하드웨어에 이식되게 
된다면 거의 확정적으로 갱신되여야 한다. 세금규약에서의 변경이 진행될 때마 
다 세금신고서를 준비하는 어떤 제품도 그에 따라 변경 되 여 야 한다. 어느 한 우 
편봉사업 체 가 1981년 9수자 ZIP 코드를 도입하였을 때 5개 수자 ZIP 코드만 허 용 
하였 던 제 품들이 변경 되 지 않으면 안되 였 다. 적 응유지 정 비 는 의 뢰 자가 요청하지 
않지 만 그대 신 의 뢰 자에 게 의 무적 으로 강요된 다. 연 구결 과는 쏘프트웨 어유지 정 
비 의 18%가 사실 상 적 응유지 정 비 이 라는것 을 보여 주었 다. 

유지정비시간의 나머지 4%는 세 가지 부류에 속하지 않는 다른 류형의 유지정비에 
돌려 졌다. 


16.2. 유지정비프로그람작성자들의 요구 

쏘프트웨어생명주기에서 다른 단계들보다 유지정비에 더 많은 시간이 소비된다. 그 
림 12-2 에서 보여 준바와 같이 사실상 제품개발에 드는 총 비용에서 평균적으로 적어도 
67%가 유지정비에 소비된다. 그러나 많은 개발기업체들은 현재까지도 보다 우수하거나 
보다 경험 이 많은 프로그람작성 자들에 게는 제 품개 발을 진행하는《 매 력적 인》업무를 맡 
기 면서 유지 정 비 과제 는 초학자들과 능력 이 부족한 프로그람작성 자들에 게 맡기 고 있 다. 

사실상 유지정비는 쏘프트웨어생산의 모든 측면가운데서 가장 어려운 과제이다. 한 
가지 중요한 리유는 유지 정 비 가 쏘프트웨 어개 발공정 의 기 타 모든 단계 들의 측면 을 포괄 
하고 있기때 문이 다. 어 떤 오유보고서 가 유지정 비프로그람작성 자에 게 넘 어 왔을 때 무슨 
일 이 발생하겠는가를 고찰하여 보자. 사용자의 견지 에서 제 품이 사용자안내서 에 명시된 
대 로 동작하지 않는 경 우에 오유보고서 가 제 출된 다. 여 러 가지 가능한 원 인들이 존재한다. 
첫째로，전혀 아무것도 틀리지 않았을수도 있다. 즉 아마도 사용자가 사용자안내서를 잘 
못 리해하였거 나 제 품을 부정 확하게 리용하고 있을수 있다. 이 와 같이 만약 오유가 제 품 
에 있다면 단순히 사용자안내서가 잘못 작성되고 코드 그자체 에는 아무런 영향이 없을수 
도 있다. 그럼 에도 불구하고 일반적으로 오유는 코드에 있다. 그러 나 유지정 비프로그람작 
성자는 그 어떤 변경을 가하기전에 사용자가 제출한 오유문서，원천코드 그리고 그밖의 
다른것들을 리용하여 어디에 오유가 있는가를 정확히 결정해야 한다. 그러므로 유지정비 
프로그람작성 자에게 는 평 균수준보다 훨씬 높은 오유수정 능력 이 필요하다. 왜 냐하면 오유 
는 제품의 그 어디에나 존재할수 있기때문이다. 그리고 오유의 근본원인이 아직까지는 
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존재하지 않는 명세서나 설계문서들에 있을수도 있다. 

유지정비프로그람작성자가 오유를 찾아 내고 제품의 다른 곳에서 실수하여 다른 오 
유 즉 회 귀 오유 ( regmw/on fault ) 를 범 하지 않고 그 오유를 수정 한다고 가정 하자. 만일 회 
귀오유가 최 소로 되 게 되 면 제 품전체 와 개 별적 제 품들에 대 한 세 부문서 작성 을 리용할수 
있 어 야 한다. 그러 나 쏘프트웨어 전문가들은 모든 종류의 문서작업，특히 문서 작성 을 하기 
싫어 한다는것은 누구나 다 아는 사실 이며 또한 문서 작성 이 불충분하거 나 오유가 있으며 
완전히 틀릴수도 있다는것은 매우 일반적인 사실이다. 이러한 경우에 유지정비프로그람 
작성자는 리용할수 있는 유일하게 정당한 문서형태인 원천코드로부터 어떤 회귀오유의 
인 입 을 피 하기 위하여 필 요한 모든 정 보들을 추출해 내 야 한다. 

가능한 오유를 결정 하고 그것 을 정 정하려 고 시 도한 다음 유지 정 비프로그람작성 자는 
변경 된 제 품이 정 확히 동작하며 그 어 떤 회 귀오유도 인입 되 지 않았다는것 을 시 험하여 야 
한다. 변경 그자체 를 검 열하기 위하여 유지 정 비프로그람작성 자는 특수한 시 험 실례 들을 
만들어야 한다. 한편 회귀오유에 대한 검열은 회귀시험을 수행하기 위하여 정확하게 저 
장한 시 험자료들의 모임 을 리용하여 수행된다 (2.7.1). 그다음 변경 을 검 열하기 위하여 구 
성한 시험실례들이 저 장된 시험실례들에 추가되 여 변경된 제품에 대 한 이 후의 회귀시 험 
에 리용되 게 된다. 이 밖에 만일 오유를 정 정하기 위하여 명세서 나 설계 에 대 한 변경 이 
진행된다면 이러한 변경들도 역시 검열되여야 한다. 그러므로 시험에서는 전문지식이 유 
지정비를 위한 추가적 인 전제 조건으로 된다. 결국 유지정 비프로그람작성 자가 모든 변경 
내 용과 문서 를 작성하는것 이 본질 적 인 문제 로 된 다. 이 과제 를 수행 하기 위하여 유지 정 
비프로그람작성자는 우선 오유의 존재여부를 결정하는 최고수준의 진단전문가로 되여야 
하며 만일 그렇게 된다면 그것을 수정하는 전문기술자가 되여야 한다. 

그러 나 기본유지정 비 과제들은 적 응유지정 비와 완전유지정 비 이다. 이 과제를 수행하 
기 위하여 유지정 비프로그람작성 자는 현존제 품을 출발점 으로 하여 요구사항확정，명세 
작성，설계，실현 및 통합단계들을 거처야 한다. 일부 류형의 변경들에 대하여서는 추가 
적인 모둘들을 설계하고 실현하여야 한다. 다른 경우들에 현존모둘들의 설계와 실현에 
대 한 변경 이 요구된 다. 결 국 명 세 서 들은 흔히 명 세 작성 전문가가 작성 하고 설 계 는 설 계 전 
문가가, 코드는 프로그람작성 전문가가 작성하는 반면 에 유지 정 비프로그람작성 자는 이 세 
개의 령역에서 모두 전문가로 되여야 한다. 완전유지정비와 적응유지정비는 교정유지정 
비와 마찬가지로 적당한 문서작성의 결과로 인하여 거꾸로 영향을 받았다. 더우기 교정 
유지정 비 에서는 마찬가지 로 완전유지정 비 와 적 응유지정 비 를 위하여 적 당한 시 험실례 들을 
설계 하고 훌륭한 명세서 도 작성할수 있는 능력 이 요구된다. 그러므로 최 고급콤퓨터 전문 
가가 진행공정을 관리하지 않는한 에 있어서 그어떤 형식의 유지정비도 경험이 어린프 
로그람작성자의 과제로 될수 없다. 

선행한 론의 로부터 유지 정 비 전문가는 쏘프트웨어 전문가가 가질수 있는 모든 기 술적 
기능들을 거의 다 소유하여 야 한다는것 이 명백하다. 그러 나 그가 무엇을 보상 받겠는가? 

1. 유지정비는 그 어떤 방식으로도 감사를 받지 못할 과제이다. 유지정비성원들은 
불만족해 하는 사용자들을 취급한다. 만일 사용자가 제품에 만족해 한다면 유지 
정비는 필요 없을것이다. 

2. 사용자가 제 기하는 문제 점 들은 흔히 유지 정 비성 원 이 아니 라 제 품을 개 발한 개 별 
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적사람들에 의하여 초래된것이다. 

3. 코드 그자체 가 잘못 작성되 여 유지 정 비 성 원의 실패 에 추가될수 있 다. 

4. 유지정비는 대부분의 프로그람작성자들로부터 차요시되는데 그■■■은 제품개발은 
매 혹적 인 업 무로 간주하며 유지 정 비 는 중간급프로그람작성 자들이 나 무능력한 프 
로그람작성 자들에게만 적 합한 단조로운 일로 생각한다. 

유지정 비는 판매후의 봉사에 비유할수 있다. 제품이 의뢰 자에게 넘 겨 졌다고 하자. 
그러나 그 제품이 정확하게 동작하지 않거나 의뢰자가 일상적으로 요구하는 모든 동작을 
하지 못하거나 제품이 만들어 질 때의 환경이 어떤 방식으로든지 변화된것으로 인하여 
의뢰자는 현재 불만족스러워 하고 있다. 만일 쏘프트웨어개발기업체가 충분한 유지정비 
봉사를 제공해 주지 않는다면 의뢰자는 장래의 제품개발업무를 다른 곳에 맡기게 될것이 
다. 의뢰자와 쏘프트웨어개발그룹이 같은 기업체에 속해 있다는것으로 하여 장래의 사업 
견지에서 서로 뒤얽혀 져 있을 때 제품에 불만족해 하는 의뢰자는 모든 정당한 또는 부 
당한 수단으로써 쏘프트웨 어그룹을 믿지 않을수 있다. 이것은 쏘프트웨 어개 발그룹의 내 
부와 외부로부터 불신임을 조성하는데로 이어 지며 이로 하여 집 단의 해산과 사직을 초 
래하게 된 다. 

그러 므로 개 발되는 매 제품에 있어서 유지정 비단계 는 쏘프트웨 어생산에서 가장 어 려 
운 단계로 되며 흔히 가장 보람이 없는 단계로 된다. 

이러한 정황이 어떻게 전환될수 있는가? 경영자들은 유지정비과제를 유지정비를 수 
행하는데 필요한 모든 기능을 소유하고 있는 프로그람작성 자들에게 맡겨 야 한다. 경영 자 
들은 가장 높은 수준의 콤퓨터전문가들만이 개 발기 업체내 에서 유지정 비 에 대 한 분담을 
받을수 있 으며 그들에 게 그에 맞는 보수를 지 불해 야 한다는것 을 깨달아야 한다. 만일 관 
리자측이 유지정비가 하나의 난관으로 되며 훌륭한 유지정비가 개발기업체의 성공을 위 
한 결정적인 고리로 된다는것은 믿게 되면 유지정비에 대한 태도가 개선되게 될것이다 
(다음의 《 알고 싶은 문제》를 보시 오.). 


알:2 싶 e ©제 

문헌《 Practical Software Maintenance 》에 서 름 피 고스키 (Tom Pigoski ) 는 자기 ; 플로 
리 다주의 펜 사를라 (Pensacola ) 에 해 군성 유지 정 비 기 업 체 (Navy maintenance organization i 를 어 
떻게 설립하였는가에 대하여 서술하고 있다 . 그의 견해는 만일 취직할 직원들이 다기가 
유지 정 비 성 원으로 일 한적 이 있다는것 을 사전에 이 야기하면 그들은 유지 정 비 에 대 i •여 긍 
정적인 래도를 가지고 있다는것이다 . 이밖에 그는 모든 직원들이 많은 양성교육 H 받게 
되며 사업과정에 세계의 모든 곳에 려행할 기회를 가지게 된다는것을 담보함으로ᅪ 그들 
의 사기도 높이 려고 시도하였다 . 아름다운 해변가는 확실히 그들이 새로 지은 건 - ■에 들 
었을 때처럼 도움이 되였다 . 

그러나 유지정비기업체가 사업을 시작한지 6 개월도 못되여 모든 직원들이 자기 - -은 언 
제 개 발과제 를 수행하게 되 는가를 물었 다 . 이 로 보아 유지 정 비 에 대 한 개 별적 사람들 - I 태 도 
를 변경시키는것은 극히 어려운 문제 인것 같다 . 
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유지정비프로그람작성자들이 현재 직면하여 있는 일부 문제점들은 실례 연구에서 고 
찰하기로 한다. 


1 6. 3. 유지정비의 실례연구 

중앙집권적경제를 운영하는 나라들에서는 정부가 농산물의 분배와 판매를 조종한다. 
이와 같은 어느 한 나라에서는 복숭아, 사과，배와 같은 온대지방 과일과 관련한 문제를 
온대과실위원회 ( rem/wrate Fruit Committee .， TFC ) 에 책임지 웠다. 어느 날 TFC 위원장이 
TFC 의 활동을 를퓨터 화하기 위하여 어 느 한 정 부를퓨터고문을 청하였 다. 위 원장은 고문 
에게 정확히 7가지 온대과일 즉 사과，살구，벗, 기름복숭아, 복숭아，배，추리가 있다는것 
을 통보하였다. 많지도 적지도 않게 이 7가지 과일에 대해서만 자료기지가 설계되였다. 
결국이것은 세계와 정부고문이 임의의 종류의 확장가능성을 리용하면서 시간과 자금을 
랑비 하지 않게 하는 방법이 였 다. 

이 제품은 정식으로 TFC 에 배포되였다. 1년쯤 지나서 위원장은 그 제품에 책임 있 
는 유지 정 비프로그람작성 자를 소환하였 다. 

위 원장은 그에 게 《 키 위 과일 에 대 하여 무엇 을 알수 있습니 까?》라고 물었 다. 어 리 둥 
절 한 프로그람작성 자는《 아무것 도 모릅니다.》라고 답변하였 다. 위 원장은 다음과 같이 
말하였다.《좋습니 다. 키위과일은 우리 나라에서 금방 재배 하기 시작한 과일 인것 갈은데 
TFC 가 그에 대 하여 책 임을 져 야 합니 다. 제품을 그에 맞게 변경하십시오.》 

유지정 비프로그람작성 자는 고문이 다행 히 도 위 원장의 처 음지 시 를 그대 로 수행하지 
않았다는것 을 발견하였 다. 어 떤 종류의 장래확장을 허 용하게 하는 훌륭 한 습관은 너 무 
뿌리 깊은것 이 여서 고문은 련관된 자료기지기록들에 여 러개의 쓰이지 않는 마당들을 만 
들어 놓았다. 일정한 항목들을 약간 재배렬함으로써 유지정비프로그람작성자는 8번째 온 
대과일인 키위를 제품안에 포함시킬수 있었다. 

또 한해 가 지 나갔는데 제 품은 잘 동작하였 다. 그때 에 유지 정 비프로그람작성 자는 또 
위원장사무실에 불리워 갔다. 위원장은 기분이 좋은 상태였다. 위원장은 프로그람작성자 
에 게 정 부가 농산물의 분배 와 판매 를 재 조직하였 다는것 을 유쾌한 기 분으로 통보하였 다. 
위원회는 이제는 온대과일뿐이 아닌 그 나라에서 생산되는 모든 과일을 책임지게 되였으 
며 따라서 제품은 위원장이 프로그람작성자에게 넘겨 준 목록에 있는 26가지의 추가적인 
과일들을 포함하도록 변경되여야 하였다. 프로그람작성자는 이러한 변경을 하려면 제품 
을 처 음부터 다시 작성하는것 과 거 의 맞먹 는 시 간이 걸 린 다는것 을 말하면서 항의하였 다. 
위원장은〈〈 허튼 소리 마시오.》라고 말하였다. 그러면서 《 당신은 아무런 애로도 없이 
키위를 추가하였소. 그러 니 그와 같은 일을 26번 반복하시 오!》라고 지 시하였다. 

이 실례로부터 여 러가지 중요한 교훈을 찾게 된다. 

1. 제품에 확장할수 있는 준비가 되여 있지 않다는 문제점은 유지정비성원이 아니 
라 개발자로부터 초래되였다. 개발자가 그 제품의 확장능력에 관하여 위원장의 
지시를 집행하는데서 오유를 범하였으나 유지정비자가 그 후과를 입었다. 사실 
초기의 제품을 개발한 고문이 이 책을 읽지 않는 한 그는 자기의 제품이 성공이 



아니라는것을 절대로 깨닫지 못할수 있다. 이것은 유지정비성원이 다른 사람의 
오유를 수정할 책임을 지게 된다는 점에서 유지정비에서 제기되는 매우 불쾌한 
한가지 측면이다. 문제를 발생시킨 당사자는 다른 임무를 맡았거나 이미 개발기 
업체를 떠 났는데 유지정 비 프로그람작성 자는 여전히 그 시달림을 받고 있는것 이 다. 

2. 의뢰자는 흔히 유지정비가 어려울수 있으며 또는 일부 경우에는 불가능하다는것을 
리해하지 못하였 다. 의 뢰 자가 보기 에 는 새 로운 유지 정 비 과제 가 이 전에 크게 애 로 
가 없 이 수행한것 과 아무런 차이 가 없는것 갈은데 유지 정 비 프로그람작성 자가 새 로 
운 유지 정 비 과제 를 수행할수 없 다고 항의하는 경 우에 문제 가 더 욱 심 각해 진 다. 

3. 모든 쏘프트웨 어개 발은 장래의 유지정 비를 반복하여 진행되 여 야 한다. 만일 고문 
이 임의의 서 로 다른 종류의 과일에 대 한 제품을 설계하였더 라면 처음에 키위를 
추가하고 그다음에 26가지의 다른 종류의 과일을 추가할 때에 아무런 애로도 없 
었 을것 이 다. 

여러번 설명한바와 같이 유지정비단계는 쏘프트웨어생산에서 사활적인 단계이며 최 
대의 자원을 소비하는 단계 이 다. 제품개 발기 간에 개발림 이 제 품이 일 단 설치된 다음에 
그 상품을 책 임지 게 된다. 유지정 비프로그람작성 자를 절대 로 소홀히 하지 않는것 이 본질 
적인 문제이다. 

1 6. 4. 유지정비의 관리 

유지정비단계에서 유지정비의 관리와 관련한 문제들을 이제 고찰하기로 한다. 

16.4.1. 오유보고서 

어떤 제품을 유지정비할 때 첫째로 필요한것은 제품을 변경시키기 위한 기구이다. 
교정유지정비 즉 잔류오유의 제거와 관련하여 만일 제품이 부정확하게 동작하는것 같으 
면 사용자에 의 하여 오유보고서 ( faw // report ) 가 작성 되 여 야 한다. 오유보고서 는 유지 정 비 
프로그람작성 자가 보통 어 떤 종류의 쏘프트웨어 오유로 될수 있는 문제 를 바로 잡는데 충 
분한 정 보를 포함하여 야 한다. 

리상적 으로 사용자가 제 기하는 모든 오유는 즉시 에 수정 되 여 야 한다. 실 천적 으로 프 
로그람개발기업체들은 개발 및 유지정비작업에서 나서는 주문잔고들의 처리로 인하여 늘 
일손이 모자란다. 만일 어떤 생활비지불명부 관리제품이 지불날자 전날 폭주되거나 직원 
들에 게 생 활비를 초과지불하거 나 모자라게 지 불하는것과 같이 오유가 치명적 이라면 즉시 
적인 정정이 진행되여야 한다. 한편 매 오유보고서는 적어도 즉시적인 예비조사를 받아 
야 한다. 

유지정비프로그람작성자는 우선 오유보고파일을 참고하여야 한다. 오유보고파일은 
아직 수정 되 지 않은 모든 보고서 오유들과 그 오유를 에 돌아 작업하는것 과 관련 한 제 안들 
즉 그 오유가 수정될수 있을 때까지 그 오유에 명백히 책임이 있는 제품의 부분들을 사 
용자가 우회하게 하는 방법 들을 포함하고 있다. 만일 오유가 사전에 보고되 였으면 이 오 
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유보고서파일에 있는 모든 정보들은 사용자에게 주어 져야 한다. 

그러나 만일 사용자가 보고한것이 어떤 새로운 오유로 될것 갈으면 유지정비프로그 
람작성자는 그 문제를 연구하고 그 원인과 수정 방도를 찾기 위 하여 노력 하여 야 한다. 왜 
냐하면 누구인가에게 그 쏘프트웨어에 필요한 변경을 진행하도록 임무가 맡겨 질 때까지 
는 6개 월 또는 9개 월 이 걸 리 수도 있기 때 문이 다. 프로그람작성 자들 특히 는 유지 정 비 를 진 
행하는데 충분히 준비 된 프로그람작성 자들이 부족하다는 사정 으로 미 루어 보아 오유가 
해결될수 있을 때까지 오유를 그냥 두고 쓰는 방법을 제안하는것이 흔히 그리 위급하지 
않는 오유보고서 를 처 리 하기 위한 유일 한 방도로 된 다. 

그다음 유지정비프로그람작성자의 결론이 그 결론에 도달할 때 리용한 목록，설계， 
지도서들과 같은 보충적인 문서작성과 함께 오유보고서에 추가되여야 한다. 유지정비를 
담당하고 있는 경 영 자는 각이한 오유들에 대 한 우선권을 부여하면서 이 파일 을 규칙 적 으 
로 참고하여야 한다. 이 파일에는 또한 완전유지정비와 적응유지정비에 대한 의뢰자의 
요구를 포함하여야 한다. 가장 높은 우선권을 가진것이 제품에 대한 다음번 변경으로 될 
것 이 다. 

어 떤 제 품에 대 한 복제본 이 여 러 싸이 트들에 배 포되 였 을 때 오유보고서 의 복제본들 
은 매 오유가 언제 수정 될 수 있는가에 대 한 평 가와 함께 모든 제 품사용자들에 게 차례차 
례 배 포되 여 야 한다. 그다음 동일 한 오유가 다른 싸이 트에 서 발생하면 사용자들은 그 오 
유를 에돌아 작업 할수 있는가와 그것 이 언제 수정될것 인가를 결정 하기 위하여 련관된 오 
유보고서를 참고할수 있다. 매 오유를 즉시에 수정하고 새로운 판본의 제품을 모든 싸이 
트들에 배포하는것이 물론 더 중요할수 있다. 현재 세계적범위에서 우수한 프로그람작성 
자들의 부족과 유지정비의 현실성으로 하여 오유보고서의 배포가 아마도 할수 있는 최선 
의 방도인것 같다. 

오유들이 일반적으로 즉시에 수정되지 못하는 또 한가지 리유가 있다. 즉 여러가지 
변경 을 진행 하고 그것들을 모두 시 험 하고 문서 를 변경 하고 새 로운 판본을 설 치하는것 이 
매 변경을 따로따로 진행 하고 그다음 그것을 시험 하고 문서화하며 새로운 판본을 설치하 
는것 보다 거의 언제 나 값이 더 눅기때 문이 다. 이것은 만일 매 새 로운 판본들이 일정한 
수량의 콤퓨터상에 설치되여야 하거나(의뢰기-봉사기망에 많은 의뢰자들이 있는것과 마 
찬가지 로) 그 쏘프트웨어 가 다른 싸이 트들에서 실행 되 고 있는 경우에 특히 그러 하다. 결 
국 개발기업체들은 치명적이 아닌 유지정비과제들을 모아 놓았다가 그다음 한개의 그룹 
으로서 변경을 실현하기를 오히려 더 좋아 한다. 

16. 4. 2. 제품에 대한 변경허가 

일단 교정유지정비를 수행하기 위한 결심이 서면 어떤 유지정비프로그람작성자에게 
실패를 초래한 오유를 결정하고 그것을 수정할 과업이 맡겨 진다. 코드가 변경된후에는 
제품전체로써 그 수정내용을 시험하여야 한다(회귀시험). 그다음 그러한 변경을 반영하도 
록 문서가 갱신되여 야 한다. 특히 무엇이 변경되였으며 그것 이 누구에 의하여 언제，무엇 
때문에 변경되였는가에 대한 자세한 서술을 변경된 매개 모둘의 서두설명문에 추가하여 
야 한다. 필요한 경우에 설계 또는 명세서도 역시 변경된다. 이와 류사한 단계들이 완전 
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또는 적응유지정비를 수행할 때에도 진행되는데 유일한 차이점은 완전 및 적응유지정비 
는 오유보고서에 의해서가 아니라 오유에서의 변경에 의하여 시작된다는것이다. 

이 시점에서 필요하다고 보이는것은 새로운 판본을 사용자들에게 배포하는것이다. 
그러 나 만일 유지 정 비 프로그람작성 자가 수정 작업 을 적 당하게 시 험 하지 않았다면 어 떻 게 
되 겠는가? 제품은 배포되 기 전에 독자적 인 그룹에 의 해 수행되 는 쏘프트웨 어 품질보증을 
받아야 한다. 즉 유지 정 비 SQA 그룹성 원들은 유지 정 비프로그람작성 자와 갈은 경 영 자에 게 
보고하지 말아야 한다. SQA 가 경영상독자성을 유지하는것 이 중요하다 (6 丄 2) 

유지정 비 가 왜 어 려운가 하는 리유는 이미 제시되 였다. 이 와 같은 리유로 하여 유지 
정비 역시 실패로 되기 쉽다. 유지정비단계에서의 시험은 어렵고 시간이 많이 랑비되며 
따라서 SQA 그룹은 시험과 관련하여 쏘프트웨어유지정비의 의의를 과소평가하지 말아야 
한다. 일 단 새 로운 판본이 SQA 그룹에 의하여 허 가되 면 그것 은 배 포될 수 있 다. 

관리자측이 절차들이 주의 깊게 준수된다는것을 담보하여야 하는 다른 하나의 령역 
은 기준선기 법과 비공식적 인 복사가 (5.8.2) 리용되는 경우이 다. 어떤 프로그람작성자가 클 
라스 TaxProvision 을 변경시키 려고 한다고 가정하자. 

이 프로그람작성 자는 그와 관련된 모둘을 고정 하고 요구되 는 유지 정 비 과제 를 수행하 
는데 필요한 다른 모든 클라스들을 복제한다. 흔히 여기 에는 그 제품안의 다른 모든 클 
라스들이 포함된다. 프로그람작성자는 TaxProvision 에 필요한 변경을 진행하고 그것들을 
시 험한다. 그리 고 이 변경 들을 병 합하고 있 는 새 로운 판본의 TaxProvision 이 기 준선에 설 
치된다. 그러나 변경된 제품이 사용자에게 배포될 때 그것은 즉시 폭주된다. 잘못한것은 
유지정비프로그람작성자가 자기 개인작업공간의 복제본을 리용하여 변경된 판본의 
TaxProvision 을 시 험 한것 이 다. 즉 TaxProvision 의 유지정 비 를 진행 할 때 기준선이 였던 다 
른 클라스들의 복제본들이 출발되 였 던것 이 다. 그사이 에 어 떤 다른 클라스들이 갈은 제 품 
에 대 하여 작업하는 다른 유지 정 비프로그람작성 자들에 의하여 갱 신되 였 다. 교훈은 명 백 
하다. 즉 어떤 모둘을 설치하기전에 그것은 프로그람작성자의 개 인용판본이 아니 라 다른 
모든 모둘들의 한개의 기준선판본을 리용하여 시험되여야 한다. 이것은 독자적인 SQA 그 
룹을 요구하는 다른 한가지 리 유이다. 즉 SQA 그룹의 성 원들은 프로그람작성 자의 개 인작 
업 공간에 전혀 접 근하지 말아야 한다. 세번째 리유는 어 떤 오유에 대 한 초기 정 정 그자체 
가 그 당시에 70%정도 부정확하다고 평가되였기때문이다 [ Pamas , 1999]. 

16. 4. 3. 유지정비가능성의 담보 

유지정비는 어느 한 때만 하는 작업이 아니다. 잘 작성된 제품은 자기 수명이상으로 
계렬화된 판본들로 발전하게 된다. 결과 전체 쏘프트웨어개발과정에서 유지정비를 계획 
하는것 이 필요하다. 실례 로 설계 단계 에서 정 보은페 수법 (7 .句이 리용되 여 야 하며 실현기 간 
에는 장래의 유지정 비프로그람작성 자들에게 의미 가 있는 변수이름들이 선택되 여 야 한다 
(14.3). 문서는 완전하고 정확해야 하며 제품의 매 요소모둘들에 대한 현재의 판본을 반 
영하고 있어야 한다. 

유지정 비단계 에서는 제품의 맨 첫 시기부터 그 제품에 실현해 놓은 유지정 비가능성 
을 손상시키지 않는것이 중요하다. 달리 말하면 쏘프트웨어개발자들이 항상 앞으로 불가 
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피하게 있게 될 유지정비에 대하여 자각하고 있어야 하듯이 쏘프트웨어유지정비성 원들도 
항상 장래의 불가피한 유지정비에 대하여 자각하고 있어야 한다. 개발기간에 유지정비가 
능성에 관하여 제정한 원리들은 유지정비단계에서도 마찬가지로 리용할수 있다. 

16. 4. 4. 반복유지정비문제 

제 품개 발을 좌절 시키 는 난점 들중의 하나는 이 동하는 목표문제 이 다 (2.2.1). 개 발자가 
제품을 구성하는것만큼 빨리 의뢰 자는 요구를 변경시 킬수 있다. 이 것은 개발림 을 좌절시 
킬뿐아니라 빈번한 변경으로 인하여 제품이 불충분하게 구성될수 있다. 이밖에 이와 같 
은 변경 들에 드는 자금이 제 품의 비 용에 추가되 게 된 다. 리 론적 으로 이 에 대 처 하기 위한 
방도는 신속원형 을 작성하는것 부터 시 작하는것 이 다. 그러 면 의 뢰 자가 요구를 아무리 자 
주 변경시켜도 문제로 되지 않는다. 일단 의뢰자가 최종적으로 만족하면 명세서가 승인 
되고 제품 그자체가 구성된다. 실천적으로 그 무엇도 요구들이 최종적으로 승인된 다음 
날로 의뢰자들이 그것을 또 변경시키는것을 가로막을수 없다. 이러한 정황에서 원형작성 
의 기본우점은 의뢰자들에게 작업모형을 줌으로써 변경의 회수와 빈도수를 줄일수 있다 
는것이다. 그러나 만일 의뢰자가 기꺼히 돈을 지불하기를 원한다면 그 무엇도 매주 월요 
일과 화요일마다 요구들이 변경되는것을 막을수는 없다. 

문제 는 유지 정 비단계 에서 악화된다. 어 떤 완성된 제 품이 많이 변경 되 면 될수륵 그 
제 품은 초기 의 설계 로부터 더 욱더 리 탈하게 될것 이 며 장래 의 변경 을 더 욱더 어 렵 게 만들 
것이다. 반복유지정비정황하에서 문서는 보통때보다 훨씬 더 믿을수 없게 될수 있으며 
회귀시 험파일들은 갱 신되지 못할수도 있다. 만일 유지정 비가 훨씬 더 많이 진행되면 제 
품전체 를 현재 의 판본을 하나의 원형 으로 리용하여 처 음부터 완전히 작성하여 야 할수도 
있다. 이동목표문제는 명백히 관리자측과 관련한 문제이다. 리론적으로 만일 관리자측이 
의 뢰 자와 충분히 결 합되 여 있 으며 프로젝 트를 실 행하는 초기 에 문제 를 설 명 한다면 요구 
들은 원형이 인입된 때로부터 제품이 배포될 때까지 고정될수 있다. 또한 완전유지정비 
에 대한 매 요청이 진행된후에 요구들은 3개월 또는 1년동안 고정될수 있다. 실천적으로 
이 런 방식 으로는 일하지 못한다. 

실례로 만일 의뢰자가 우연히 회사의 사장으로 되고 개발기업체는 그 회사의 정보체 
계부서라면 사장은 실지 로 매 주 월요일과 화요일에 변경 을 주문할수 있으며 그런 변경들 
은 실현될것 이 다.《 비 용을 부담하는 사람에 게 결정 권이 있 다.》는 옛 날 속담은 공교롭게 
도 이 정황에 너무도 적합하다. 아마 정보체계의 부책임자가 할수 있는 최선의 방법은 
사장에게 반복유지정비가 제품에 주는 영향은 이후의 유지정비가 제품의 통합에 위험을 
가져 올 때 마다 그 완성된 제 품을 단순히 다시 작성하게 하는것 이 라는것 을 설명하려 고 
시도하는것일수 있다. 

요구되 는 변경 이 천천히 실현된다는것 을 담보함으로써 추가적 인 유지 정 비 를 방해하 
려고 하는것은 이와 관련 있는 직원을 유지정비를 보다 빨리 할수 있는 다른 직원으로 
교체하는 결과만을 초래할것 이 다. 간단히 말하여 반복변경 을 요구하는 사람이 충분한 권 
한을 가진 사람이 라면 이동목표와 관련한 이 문제를 해결할 방도는 더는 없다. 
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16.5. 객체지향쏘프트웨어의 유지정비 

객체지향파라다임을 리용할것을 권고한 한가지 리유는 그것이 유지정비를 촉진시킨 
다는것이다. 결국 하나의 객체는 어떤 프로그람의 하나의 독립적인 단위이다. 보다 명확 
하게 말하면 잘 설계된 객체는 교갑화(대로 알려 진 개념적독립성을 나타낸다 
(7.4). 실세계 의 부분과 관계 되 는 제 품의 매 개 측면은 객 체 그자체 로 국부화된 다. 이 밖에 
객체는 물리적독립성을 나타낸다. 즉 실현세부들은 그 객체의 밖에서 볼수 없다는것을 
담보하기 위하여 정 보은페수법을 인입 한다 (7 .句. 허 용되는 정 보전달의 유일한 형 식은 어 
떤 특정한 객체를 호출하기 위하여 그 객체 에 통보를 보내는것 이 다. 

결과 론리적 으로 보면 다른 두가지 리 유로 하여 객체 를 유지정 비하는것 이 쉬워 질것 
이 다. 첫째 로, 개 념적독립성은 어떤 특정한 유지정 비목표를 달성 하기 위하여 제품의 어 느 
부분이 변경되여야 하며 그것이 확장유지정비인가 아니면 교정유지정비인가를 쉽게 결정 
하게 할것 이 라는것을 의미한다. 둘째 로, 정보은폐는 어떤 객체 에 가해 질 변경 이 그 객체 
의 밖에 서 충돌하지 않을것 이 며 그로 인 하여 회 귀오유의 수가 크게 감소된 다는것 을 담보 
한다. 

그러나 실천적으로 정황은 이처럼 랑만적인것은 아니다. 사실 객체지향쏘프트웨어에 
특정한 세 가지 장애 가 존재한다. 그중 한가지 문제 는 적 당한 CASE 도구를 사용하는것 을 
통하여 해결될수 있지만 다른것들은 처리하기가 쉽지 않다. 먼저 그림 16-2 에 보여 준 
C ++ 클라스계층도를 고찰하자. 방법 displayNode 는 클라스 UndirectedTree 에서 정의되고 
클라스 DirectedTree 에 의 하여 계승되며 그다음 쿨라스 RootedTree 에 서 재정의된다. 
재 정 의된 판본은 클라스 BinaryTree 와 클라스 BalancedBinaryTree 에 의해 계 승되 며 
클라스 BalancedBinaryTree 에 서 리 용된다. 그러 므로 유지 정 비 프로그람작성 자는 클라스 
BalancedBinaryTree 를 리 해 하기 위 하여 완전 한 계 승계 층도를 연구하여 야 한다. 

보다 불리한 경우에 계층도가 그림 16-2 의 선형형식으로 현시되지 않을수도 있지만 일 
반적 으로 전체 제품에 전개 되 여 있 다. 그러므로 클라스 BalancedBinaryTree 에 서 displayNode 
가 무슨 역할을 하는가를 리해하기 위하여서는 유지정비프로그람작성자가 제품의 중요 
부분들을 통독하여야 할수 있다. 이것은 이 절의 서두에서 서술한《독립적인》객체와는 
철저한 차이 가 있다. 이 문제의 해 결은 간단하다. 즉 적 당한 CASE 도구를 리 용하면 된 
다. C ++ 름파일 러 가 클라스 BalancedBinaryTree 의 실례내 에서 displayNode 의 판본을 정 확 
히 결정할수 있기때문에 프로그람작성작업대는 어떤 클라스의 《 단조로운》판본 즉 임의의 
이름재작성 또는 재정의를 병합함으로써 직접적으로 또는 간접적으로 계승되는 모든 명백한 
특성들을 가지고 있는 클라스의 정의를 제공하여 준다. 그림 16-2 에 서 클라스 
BalancedBinaryTree 의 단조로운 형식은 콜라스 RootedTree 로부터 displayNode 의 정의를 
포함한다. 단조로움을 실 현 하기 위 한 CASE 도구들은 C ++ 또는 Java 에 만 국한되 여 있지 
않다. 실례로 에필 ( Eifell ) 은 이러한 목적을 위하여 명령 flat 를 포함하고 있다 [ Meyer , 1990]. 

객 체지향언어 를 리용하여 실현된 제품의 유지정 비 에서의 두번째 장애 는 해 결하기 가 
그리 쉽 지 않다. 이 문제 는 7.8 에 서 설명한 개 념 들인 다형 성 과 동적맺 기 의 결과로서 발생 
한다. 이 절에서 한가지 실례가 주어 졌는데 여 기에서는 기초콜라스를 세개의 부분콜라 
스 즉 DiskFileClass, TapeFileClass, DisketteFileClass 들과 함께 FileClass 로 이 름 지 었 다. 
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void dislayNode ( Node a); 

} // 믈라스 UndirectedTree 

class DirectedTree: public UndirectedTree 

{ 

} // 콜라스 DirectedTree 

class RootedTree: public DirectedTree 

{ 

void displayNode ( Node a); 

} // 들라스 RootedTree 


class BinaryTree: public RootedTree 


} // 들라스 BinaryTree 

dass B 신 ancedBinaryTree: public BinaryTree 
{ ‘ 。 

Node hhh; 

DisplayNode (hhh); 

} // 콜라스 BalancedBinaryTree 

그림 16-2. 콜라스계층의 C++ 실현 

이것은 그림 7-33 에 제시되 였는데 편리를 도모하기 위하여 이 장에서 그림 16-3 으로 
다시 제 시 하였 다. 기 초클라스 FileClass 에 서 하나의 무의 미 한 (abstract 또는 virtual ) 방법 
open 이 선언된다. 그다음 이 방법의 특정한 실현이 세개의 부분클라스들에 각각 반영된다. 
즉 매 방법은 그림 16-3 에 보여 준바와 같이 동일한 이름 open 으로 주어 진다. myFile 이 
하나의 객체 즉 FileClass 의 하나의 실례로 선언되고 유지정비되여야 할 코드안에 통보 
myFile.open( ) 이 포함된다고 가정 하자. 다형 성 과 동적맺 기 의 결과로서 실행 시 에 myFile 은 
FileClass 에서 파생된 세개의 클라스 즉 디스크파일，레프파일，자기원판파일의 한 성원으 
로 될수 있다. 일 단 실시 간체 계 가 그 클라스가 어 디서 파생되 였는가를 결정하면 open 의 
적당한 판본이 호출된다. 

이것은 유지정비에 불리한 결과를 가져 올수 있다. 만일 유지정비프로그람작성자가 
코드에 서 호출 myFile.open( ) 을 만나게 되 면 제 품에 서 이 부분을 리 해 하기 위 하여 myFile 
이 세개 부분콜라스의 매 개의 한 실례 로 되는 경우 무슨 현상이 발생하겠는가를 고찰하 
여 야 한다. CASE 도구는 여 기서 도움이 될수 없다. 왜 냐하면 일 반적 으로 정 적방법들을 리 
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용하여 동적 맺기를 결정 할 방도가 없기 때문이 다. 

여 러개의 동적맺 기들가운데서 어느것 이 특수한 정황모임 안에서 실지로 발생 하였는가 
를 결정하기 위한 유일한 방도는 해당한 코드를 어떤 콤퓨터상에서실행시키든가 수동적 
으로 추적 하면서 코드를 추적 하는것 이 다. 다형성과 동적맺 기는 사실상 객체지 향제품의 
개 발을 촉진시키 는 매우 강력 한 객체지 향기술측면들이 다. 그러 나 그것들은 유지정 비 프로 
그람작성자가 실행시에 발생할수 있는 다양한 형태와 가능한 결합들을 조사하고 그로부 
터 여러개의 각이한 방법들중에서 어느것이 코드안의 그 개소에서 호출될수 있는가를 결 
정 하도록 함으로써 유지정 비 에 유해 로운 영향을 줄수 있다. 


| 함 수 open_disk_ffle | | 힘 ■ 수 open_tape_file | I 함 수 open_diskette_file I 

기 



L) 


그림 16-3. 도출콜라스 DiskFileClass, TapeFileClass, DisketteFileClass 를 
가진 기 초클라스 FileClass 의 정 의 

세번째 문제 는 계 승의 결 과로써 발생한다. 어 떤 특정한 기 초클라스가 새 제 품의 설 
계에서 요구되는 전부는 아닌 대부분의 과제를 수행한다고 가정하자. 

이제 하나의 파생클라스를 정의하자. 즉 이 클라스는 많은 점 에서 기 초콜라스와 같지 
만 새로운 특성들이 추가될수 있으며 현존 특성들이 다시 이름 지어 지거나 다시 실현되 
여 압축되거나 기타 다른 방식으로 변경될수 있다. 더우기 이러한 변경들은 기초들라스 
또는 임의의 기타 파생클라스들에 아무런 영향을 주지 않으면서 진행될수 있다. 그러나 
이제 기초클라스자체가 변경된다고 가정하자. 만일 그렇게 되면 모든 파생클라스들이 같 
은 방식으로 변경된다. 달리 말하면 계승의 우점은 새로운 잎들이 계승나무에서 그 어떤 
다른 클라스들을 변경시키지 않으면서 계승나무(만일 실현언어가 c — H 서처럼 다중계승 
을 지원한다면 그라프로 된다.)에 추가될수 있다는것이다. 결국 계승은 개발에는 긍정적인 
영 향을 주지 만 유지 정비에 는 부정 적 영향을 줄수 있는 객 체 지 향수법의 또 한가지 특성 이 다. 
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1 6. 6. 유지정비기능 대 개발기능 

이 장의 앞에서 유지정비에 요구되는 기능들에 대하여 많이 설명하였다. 교정유지정 
비에 있어서는 대규모제품의 실패원인을 결정하는 능력이 필수적으로 요구된다. 그러나 
제품유지정비에서는 이와 반대로 이러한 능력이 요구되지 않는다. 이 기능은 통합과 제 
품시험 전 기 간에 리용된다. 또 한가지 사활적 인 기능은 적 당한 문서 작성을 진행하지 않 
고 효과적으로 기능을 수행할수 있는 능력이다. 게다가 문서작성은 통합과 제품시험 이 
진행되는 기간에는 좀처럼 완성되지 않는다. 또한 강조해야 할것은 명세서작성, 설계, 실 
현과 통합과 관련한 기능들이며 시험이 적응 및 완전유지정비에서 본질적으로 중요하다 
는것이다. 이러한 활동들은 역시 개발공정에서도 수행되며 그 매개는 그것이 정확하게 
수행되여야 한다면 전문화된 기능들을 요구한다. 

달 리 말하면 유지 정 비 프로그람작성 자에 게 필요한 기 능들은 쏘프트웨 어 생산의 다른 
단계 들에 전문적 으로 봉사하는 쏘프트웨 어전문가들에 게 필요한 기 능들과 방법상 아무러 
한 차이도 없다. 중요한 점은 유지정비프로그람전문가들이 다양한 령역들에 단순히 숙련 
될것이 아니라 그 모든 령역에 고도로 숙련되여야 한다는것이다. 비록 평범한 쏘프트웨 
어개발자가 설계나 시험과 갈은 쏘프트웨어개발의 한 령역에 전문화될수 있다고 하여도 
쏘프트웨 어유지정 비성원은 사실상 쏘프트웨 어생산의 모든 령 역에 대 한 전문가로 되 여야 
한다. 결국 유지정비는 개발이나 다름이 없거나 또는 그이상으로 될수 있다. 

16. 7. 역 공 학 

때때로 지적한바와 같이 유지정비에 리용할수 있는 유일한 문서는 원천코드 그자체 
이 다(이 러 한 경 우는 기 존체 계 (/egmy system ) 즉 현재 리 용하고 있지 만 15년 또는 20년전 
에 개발된 쏘 프트웨 어를 유지정비할 때에 매우 자주 발생한다.). 이러한 정황하에서 코드 
를 유지정비하는것은 매우 어려울수 있다. 이러한 문제를 처리하기 위한 한가지 방도는 
원천코드로부터 출발하여 설계문서 나 지 어는 명세서를 다시 작성하려 고 시도하는것 이 다. 
이 러한 과정을 역공학 〈reverae engineering ) 0 ] efoL 한다. 

CASE 도구들이 이 과정 을 도울수 있다. 한가지 가장 간단한 실례는 기 묘한 인쇄프로 
그람 (5.6) 인데 이것은 코드를 보다 명백히 현시할수 있도륵 도와 줄수 있다. 다른 도구들 
은 원천코드로부터 직접 흐름도나 UML 선도과 같은 선도들을 구성하는데 이러한 시각적 
인 수단들은 설계회복과정을 도울수 있다. 일 단 유지정비림 이 설계를 재구성하였다면 두 
가지 가능성 이 존재 하게 된다. 하나의 대 안은 명세서 를 재 구성 하고 재 구성 된 명세 서 를 
변경하여 필요한 변경 들을 반영하며 제 품을 보통 방식 으로써 재 실현하는것 이 다(역 공학의 
범위내 에서 명세서의 작성 으로부터 설계를 통하여 코드작성 에 로 나아가는 일 반적 인 개 발 
공정 을 정 공학 (/ bnvarc / engineering ) 0 ] efoL 부론다. 역 공학에 뒤 이 은 정 공학을 때 로 재 공학 
{ reengineering ) 0 } 부른다.). 실천적 으로 명세서 의 재 구성 은 매 우 어 려 운 파제 이 다. 흔 
히 재작성된 설계는 변경되며 변경된 설계는 그다음 정공학적으로 실현된다. 유지정비단 
계에서 흔히 실현되는 련관된 활동은 재구성 ( ms / rwc / Mr / ng ) 이다. 역공학은 제품을 보다 낮 
冬 준위의 추상화로부터 보다 높은 준위의 추상화에 로 례하면 코드로부터 설계 에 로 끌어 
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올린다. 정공학은 보다 높은 준위의 추상화로부터 보다 낮은 준위의 추상화에로 제품을 
끌어 내린다. 그러나 재공학은 갈은 준위에서 진행된다. 재구성은 제품의 기능을 변경시 
키지 않고 제품을 개선하는 과정이다. 기묘한 인쇄프로그람은 재구성의 한가지 형태이다. 
그러므로 코드는 비구조화된 형식으로부터 구조화된 형식으로 전환된다. 일반적으로 재구성 
은 원천코드(또는 설계 지어는 자료기지)를 보다 쉽게 유지정비하기 위하여 진행된다. 

만일 원천코드가 류실되고 리용할수 있는것이 제품의 실행판본인 경우에 정황은 더 
욱 불리해 진다. 얼핏 보기에는 원천코드를 재생하기 위하여 유일하게 가능한 방도는 역 
아쌤블러 를 리 용하여 역 아쌤 블리 어 코드를 생성 하며 원래의 고급언어 코드들을 재생 할수 
있게 하는 코드(이것을 역를파일러라고 부를수 있다.)를 구성하는것이다. 이 방법에는 사 
실상 극복할수 없는 여 러 가지 문제점들이 동반되게 된다. 

1. 변수의 이름이 본래의 를파일의 영향으로 류실될수 있다. 

2. 대부분의 를파일러들은 어떤 방법으로 코드를 최량화하는데 이것은 원천코드를 
재생하려 고 시도하는것을 매우 어 렵게 한다. 

3. 아쌤블리 어 에서 순환과 같은 구조는 원천코드에서 여 러가지 서로 다른 가능한 
구조들에 대응할수 있다. 

그러므로 실천적으로 현존 제품은 검은통으로서 취급되며 역공학은 현재제품의 거동 
으로부터 명세서를 도출해 내는데 리용된다. 재구성된 명세서들은 필요할 때 변경되며 
제품의 새로운 판본은 이 명세서로부터 정공학적수법으로 실현된다. 

16.8. 유지정비단계에서의 시험 

제품이 개발되는 동안에 개발림의 많은 성원들이 제품전반에 대한 폭넓은 견해를 가 
지게 되지만 콤퓨터산업에서의 인재들의 빠른 교체로 인하여 유지정비에 참가하는 유지 
정 비 림성 원들은 초기개 발에 참가하지 못하였을수도 있다. 그러므로 유지정 비성원들은 제 
품을 제각기 련관된 모둘들의 모임으로 보는 경향이 있으며 한개 모둘에 대한 변경이 한 
개 또는 그이상의 다른 모둘들에 심각한 영향을 주며 나아가서 제품전반에 영향을 주게 
된다는것을 일반적으로 깨닫지 못한다. 비록 유지정비성원이 제품의 모든 측면을 리해하 
려고 애 쓴다고 하여도 제품을 수정하거나 확장하는데서 난관은 이 목적을 달성하기 위 
하여 요구되는 상세한 연구에 시간을 돌릴수 없다는것이다. 더우기 많은 경우에 이러한 
리해를 진행할 때 도움이 되도록 리용할수 있는 문서가 적거나 전혀 없다. 이와 같은 난 
관을 최소로 줄이기 위한 한가지 방법은 회귀시험의 리용 즉 변경된 제품이 여전히 정확 
히 동작한다는것을 담보하기 위하여 선행한 시험실례들과 대비하여 변경된 제품을 시험 
하는것이다. 이러한 리유로 하여 모든 시험실례들을 예상되는 결과와 함께 기계가독한 
형식으로 저장하는것이 사활적인 문제로 된다. 제품에 대한 변경의 결과로 일부 저장된 
시험실례들이 변경되여야 할수 있다. 

실례로 만일 세금법제정의 결과로 로임 원천과세 률이 변화되면 로임지불명 단관리제품 
의 정확한 출력은 원천과세를 포함하고 있는 매 시험실례에 관하여 변화될것이다. 이와 
류사하게 만일 위성관측결과 어떤 섬의 위도와 경도가 수정된다면 그 섬의 좌표를 리용 
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하여 비행기의 위치를 계산하는 어떤 제품의 정확한 출력도 따라서 변화될것이다. 수행 
된 유지정비에 따라서 일부 정당한 시험실례들이 부정당하게 되여 버릴것이다. 그러나 
저 장된 시 험 실 례 들을 교정 하기 위 하여 진행 할 계 산들은 유지 정 비 가 정 확하게 수행 되 였 다 
는것을 시험하기 위한 새로운 시험자료들을 구성하기 위하여 진행하여 야 할 계산과 본질 
에 있어서 갈다. 그러므로 시험실례들과 예상되는 결과들을 저장하고 있는 파일을 유지 
정비할 때 그 어떤 추가적인 작업도 필요 없다. 회귀시험은 시간을 랑비한다고 론의될수 
있다. 왜냐하면 회귀시험은 완성제품의 제품유지정비과정에 변경된 모둘들과 명백히 아 
무런 관련도 없는 많은 시험실례들에 대하여 재시험될것을 요구하기때문이다. 여기서 
《명백히》라는 단어가 결정적의미를 가진다. 미처 의식하지 못한 유지정비의 측면영향 
의 위험(즉 회귀시험의 인입이 실패한다.)은 매우 커서 이러한 론증을 무의미하게 만든다. 
즉 회귀시험은 그 어떤 정황에서도 유지정비의 본질적인 한가지 측면으로 된다. 

16.9. 유지정비단계에서의 CASE 도구 

유지정비프로그람작성자가 어떤 모둘이 갱신될 때마다 각이한 재판본번호들을 수동 
적으로 추적하여 다음번 판본번호들을 할당하리라고 생각하는것은 부당한 일이다. 조작 
체계가 판본조종기능을 포함하고 있지 않는 한에서는 UNIX 도구 sccs(source code control 
system )[ Rochkind , 1985], rcs(revision control system )[ Tichy , 1985] 王去 c vs (concurrent 
versions system)[Loukides and Oram , 199 刀과 같은 어떤 판본조종도구가 요구된다. 제5장에 
서 서술한 동결기 법의 수동조종이든가 또는 재판본이 적 당하게 갱 신된다는것을 담보하는 
기타 수동적인 방법들을 기대하는것도 역시 부당한 일이다. 필요한것은 하나의 구성조종도 
구이 다. 시장에서 판매되는 한가지 전형적 인 도구는 CCC(change and configuration control ) 
이다. 비록 쏘프트웨어개발기업체가 완전한 구성조종도구를 구입하려고 하지는 않는다고 
하여도 최 소한 구축도구(뇨加 tool ) 는 어떤 판본조종도구와 결합하여 리용되 여 야 한다. 유 
지정비 단계 에서 사실상 본질적역 할을 하는 또 다른 부류의 CASE 도구들은 아직 수정되지 
않는 발견오유들에 대한 기록을 유지하게 하는 오유추적도구이 다. 

16.7 에서 역공학과 재공학을 지원할수 있는 몇가지 부류의 CASE 도구들을 서술하였 
다. 제 품구조에 대 한 시 각적 현실 을 생 성하는것 으로써 지 원을 주는 이 와 같은 도구들로서 
는 Battlemap , Teamwork , Bachman Reengineering Product Set 들을 실례로 들수 있다. 

유지정비는 어렵고 실패하기 쉽다. 관리자측이 최소한 할수 있는것은 유지정비림에 
효과적이고 또 효과적인 제품유지정비에 필요한 도구들을 제공하여 주는것이다. 

16. 10. 유지정비단계에서의 척도 

유지정비단계에서 진행되는 활동은 본질에 있어서 명세작성，설계，실현，통합，시험， 
문서작성이다. 그러므로 이러한 활동들을 재기 위한 척도들은 유지정비단계에서도 그대 
로 리용할수 있다. 실례 로 14.8.2 의 복잡성 척 도는 높은 복잡도를 가진 어 떤 모둘이 회 귀 
오유를 포함하는 후보로 될것 같다고 하는 점에서 유지정비와 관련된다. 이와 같은 모둘 
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을 변경할 때에는 특별히 주의를 돌려야 한다. 

이밖에 유지정비단계에 특정한 척도들로서는 보고된 오유의 총 개수와 이 오유들의 
엄중성과 종류에 따르는 분류와 갈은 쏘프트웨어오유보고서와 관련된 측도들을 들수 있 
다. 이밖에 오유보고서의 현재상태와 관련한 정보들도 요구된다. 실례로 2002년에 13개의 
치명적오유들이 보고되 고 수정되 였다는것과 그 해 에 2개의 치 명적오유만이 보고되 고 수 
정 되 지 않았다는것 사이 에 는 상당한 차이 가 있는것 이 다. 

16. 11. 항공음식전문회사 실례연구 : 

유지정비단계 

여 러 가지 오유들이 이 실례연구의 원천코드에서 발견되 였 다. 그중 3개 를 발견하여 
정 정하는것 을 련습문제 로서 남겨 둔다(문제 16.11~16.13까지 ). 

16. 12. 유지정비단계에서의 난관 

유지정 비단계 에서의 기 본 난관들은 1.3 의 《 알고 싶은 문제》에서 자세 히 설명하였 다. 
간단히 말하여 고전적 쏘프트웨어 공학은 선개발후 유지 정비 初로 

써 설 명할수 있 다. 즉 먼 저 제 품의 령 상태 로부터 개 발되 여 의 뢰 자에 게 배 포된 다. 그때 로 
부터 제품에 대하여 유지정비가 진행된다. 이와 갈은 선개발후유지정비모형은 다음과 같 
은 IEEE 규격 610. 12의 정의 와 일 치한다. 즉 《 쏘프트웨어 가 의 뢰 자에 게 배 포되 기전에 수 
행되는 모든 쏘프트웨 어생산활동은 개 발로 간주되며 배포이후의 모든 활동들은 유지정 비 
를 구성한다 .》 [IEEE 610.12, 1990] 

선개 발후유지 정 비모형 은 오늘날 비 현실 적 이 다. 

1. 의 뢰 자의 요구는 제 품이 배 포되 기전에 자주 변한다. 

2 . 오유들은 흔히 제 품이 배 포되 기전에 수정 되 여 야 한다. 

3. 령상태로부터의 개발은 점차 드물어 지고 있다. 반대로 제품의 대부분은 재리용 
된 요소들밖에서 구성되며 이러한 재리용된 요소들은 그것들이 새 제품에서 리 
용될수 있기전에 자주 변경될 필요가 있다. 

이 와 같은 세 가지 리 유로 하여 제 품은 거 의 언제 나 배 포되 기 전에 변경 되 여 야 하며 
이러한 변경들을 진행할 때에 수행된 활동들은 고전적유지정비에서의 활동과 구별할수 
없다. 

유지정 비의 실제의미 는 KO / IEC 규격 12207에서 제정 되 였는데 여 기 에서 는 유지정 비공 
정 은 《 쏘프트웨 어 가 어 떤 문제 나 개 선 또는 적 응에서의 필요로 인하여 코드와 련관된 
문서에 의하여 변경을 거처야 할》때 작용된다고 서술하고 있다 [ ISO/IEC 12207, 1995]. 

쏘프트웨어 공학집단의 보다 광범한 계 층이 《 유지 정 비》는 쏘프트웨어 생 명 주기 의 전반 
에 걸쳐 수행되는 활동이 라는것을 인정 하게 될것 이 다. 이것은 유지정 비단계 뿐아니 라 전반적 
쏘프트웨 어 개 발공정 에 중요한 개 선을 가져 오게 될 것 이 다. 
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요 약 


유지정 비는 중요하고도 어 려운 쏘프트웨 어활동이 다 (16.1 과 16.2). 이것을 16.3 의 실 
례연구로써 례 증한다. 반복유지정 비 문제 를 비 롯하여 유지 정 비 의 관리 와 관련된 문제 들 
을 서 술한다 (16.4). 객체지향쏘프트웨어의 유지정 비 는 16.5 에서 론의된다. 유지정 비프로 
그람작성자에게 요구되는 기능은 개발자에게 필요한 기능과 갈다. 차이는 개발자는 쏘 
프트웨어개 발공정 의 한 측면 에 전문화될 수 있 으며 반면 에 유지정 비 성 원은 쏘프트웨 어 
생산의 모든 측면에서의 전문가로 되여야 한다는것이다 (16.6). 역공학에 대한 설명은 
16.7 에 서 술되 였다. 유지정 비단계 에서 의 시 험 (16.8) 과 유지정 비단계 에서 의 CASE 도구 
(16.9) 들에 대 한 설명 을 진행한다. 유지정 비단계의 척 도는 16.10 에서 론의된다. 항공음 
식전문회사의 실례연구에 대한 유지정비는 16.11 에서 제시되였는데 련습으로 남겨 두 
었다. 이 장은 유지정 비단계 에서 의 난관에 대 한 론의 로 결속된다 (16.12). 

보 충 

유지 정 비 에 대 한 고전적 인 정 보원 천은 문헌 [Lientz and Swanson, 1980] 이 다. 유지 정 비 
에 대 한 유용한 자료는 문헌 [Longs 仕 eet, 199 이에서 볼수 있다. 문헌 [BasiU, 199 이은 재 리 
용과정과 마찬가지로 유지정비에 대한 흥미 있는 견해를 서술하고 있다. 회귀시험은 문헌 
[Rothermel and Harrold, 1996] 에 서 분석 하였 다. 그 비 용상효과성 에 대 한 예 견에 대 하여 서 는 
문헌 [Rosenblum and Weyuker, 199 기에서 서술하고 있다. 공업환경 에서의 회귀시 험은 문헌 
[Onoma, Tsai, Poonawala, and Suganuma, 1998] 에 서 론의 하였 다. 재 공학에 대 한 계 획 작성 은 
IEEE Software 1995 년 1 월호에 있는 재공학에 관한 많은 기사들중의 하나인 문헌 [Sneed, 
1995] 에서 서술하고 있다. 재공학의 비 용과 리익성 에 대 하여서 는 문헌 [Adolph, 1996] 에서 
론의 하였다. 문헌 [Charette, Adams, and White, 199 刀은 유지정 비의 기 본틀거 리 안에서 위 험 
성 관리를 서 술하고 있다. 그리 고 문헌 [von Mayrhauser and Vana, 199 기은 큰 규모제품의 
유지정 비를 위한 여 러 가지 프로그람리해기구를 서술하고 있다. 아주 성공적 인 재공학프로 
직 트의 륜곽에 대 하여 문헌 [Teng, Jeong, and Grover, 1998] 에 서 서 술하여 주고 있다. 정 보 
체계의 유지정비는 문헌 [Bisbal, Lawless, Wu, and Grimson, 1999] 에서 서술하여 주고 있 
다. 유지가능성 의 범 위안에 서 척 도의 리용에 대 하여 서 는 문헌 [Banker, Datar, Kemerer, and 
Zweig, 1993, and Henry, Henry, Kafura, and Matheson, 1994] 에서 론의하였다. 객체의 리용에 
서 유지정비의 영향은 문헌 [Henry and Humphrey, 1990, and Mancl and Havanas, 199 이에서 
서 술하고 있 다. 특정한 객 체지 향제 품의 유지정 비 는 문헌 [Lejter, Meyers, and Reiss, 1992, 
and Wilde, Matthews, and Huitt, 1993] 에서 서술하여 주고 있다. 쏘프트웨 어 유지정 비와 관련 
한 론문은 Communication of the ACM 1994 년 5 월 호에 서 찾아 볼수 있 다. IEEE Software 
1998 년 7 월/ 8 월호에는 기존체계에 대한 많은 기사들이 들어 있으며 여기에는 특히 문헌 
[Rugaber and White, 1998] 이 있 다. 쏘프트웨 어 유지 정 비 에 관한 대 회 회 보는 유지 정 비 의 모 
든 측면에 대하여 기초로 되는 폭넓은 정보원천으로 되고 있다. 
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문 제 


16.1. 당신은 무엇 때 문에 오유가 쏘프트웨 어 유지 정 비 가 쏘프트웨 어개 발보다 못하다고 
간주하는데 로부터 생 긴 다고 생 각하는가? 

16.2. 콤퓨터에 비루스가 있는가를 결정하는 제품을 고찰하자. 이러한 제품에서 왜 
그 모둘의 대 부분이 다중변화될것 같은가를 설명 하시 오. 그 결과 발생하는 문제 는 어 떻 
게 해결될수 있는가? 

16.3. 문제 8. 7 의 자동서 고순환체 계 에 대 하여 문제 16. 2 를 반복하시 오. 

16.4. 은행계 산서 가 정 확한가를 시 험하는 문제 8.8 의 제 품에 대 하여 문제 16.2 를 반복 
하시오 

16.5. 문제 8.9 의 자동출납기에 대하여 문제 16.2 를 반복하시오. 

16.6. 당신은 대규모쏘프트웨어개발기업체안의 유지정비를 책임진 경영자이다. 당신 
은 새로운 직원을 채용할 때 무슨 자질을 중요시하겠는가? 

16.7. 직 원 이 한명 인 쏘프트웨 어 개 발기 업 체 에 서 유지 정 비 의 의 미 는 무엇 인가? 

16.8. 당신은 어 떤 콤퓨터화된 오유보고서파일 을 구성할데 대 한 요청 을 받았다. 그 
파일에 무슨 종류의 자료를 저장하겠는가? 당신의 도구는 무슨 종류의 질문들에 
답변할수 있는가? 또 무슨 종류의 질문들에 답변할수 없는가? 

16.9. 당신은 Ye Olde Fashioned Software Corperation (문제 15.6) 의 쏘프트웨 어유지 정 비 
부책임자로부터 한통의 편지를 받았다. 편지에서는 가까운 앞날에 Olde Fashioned 가 수 
천만행에 달하는 COBOL 코드를 유지정비하게 된다는것을 지적하고 이러한 유지정비를 
위한 CASE 도구와 관련하여 당신의 권고를 부탁하고 있다. 당신은 어 떻게 답변하겠는가? 

16.10. (과정안상 목표) 브로드랜 즈지 역 아동병 원(부록 1) 의 가족면회 분과에 서 제 공하 
는 무임수송 및 숙박봉사는 현재 부모들이 브로드렌즈의 926km 반경내 에 살고 있는 어 
린이들에게 제한되여 있다. 이제 이 제한이 제거되게 된다. 문제 15J0 의 제품에 대하여 
무슨 변경을 하여야 하는가? 당신의 대답을 문제 1.11 에 준 대답과 비교하시오. 

16.11. (실례연구) 일 단 어떤 좌석 이 한 승객 에게 할당되 였으면 다른 승객 에 게는 배 
당될수 없도록 15.13 의 실현을 정정하시 오. 

16.12. (실 례연구) 항공음식 전 문회 사 실례연구에 13 종류의 특별식 사가 있 다. 그러 나 
15.13 의 실현에는 프로그람작성자가 12 종류만 있다고 생각하게 할것 같은 개소들이 있다. 
그 실현을 적 당히 수정하시 오. 

16.13. (실례연구) 15.13 의 실현은 사용자가 식사품질을 입력할 때 그 값이 1 부터 5 사 
이 에 있 다는것 을 검 열하지 않는다. 이 오유를 수정하시 오. 

16.14. (실례연구) 15.13 의 실현에 서 매 요소들의 중심 맞추기 를 조절 함으로써 모든 보 
고서들의 미학적인 표현방식을 개선하시오. 

16.15. (실례연구) 15.13 의 실현에서 차림 표구동입 력부분프로그람을 도형사용자대 면부 
로 교체하시 오. 

16.16. (쏘프 트웨 어 공학독본) 교원은 문헌 [Rugaber and White, 1998] 의 복제 본을 배 포 
할것 이 다. 당신은 기 존체 계 를 유지 정 비하는데 서 가장 큰 난관이 무엇 이 라고 보는가? 
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부록 1 . 브로드랜즈지역 아동병원 


브로드랜즈지 역 아동병 원 (SroacZ/a/Kfo Area Children's Hospital •’ BACH) 은 브로드랜 
즈시의 반경 926km 안에서 살고 있는 어린이들에게 전문화된 소아과치료를 제공하여 
준다. 이밖에 세계 각지에서 환자들이 자기 나라에서는 받을수 없는 치료봉사를 받기 
위하여 브로드렌즈로 온다. 입 원환자들의 평 균입 원기 간은 3.6 일 이 다. 그러 나 일부 어 
린이들은 병을 회복하는데 상당히 오랜 시일이 걸리며 6 개월부터 9 개월까지 입원하는 
경우가 드물지 않다. 

리상적 인 경우에 모든 환자들은 BACH 에 입원해 있는 전 기간 보호자와 함께 있게 
된다. 그러나 여러가지 리유로 인하여 일부 어린이들은 입원 전 기간 또는 일정한 기간 
자기 혼자 있게 된다. 다른 한가지 문제는 BACH 환자들의 대다수 부모들이 재정적곤난을 
겪고 있는것이다. 부모들은 자기 아이들에게 놀이감，학습장, 크레용 등을 즐겨 보장해 
주어 야 하겠지 만 그들에게는 그렇게 할 재정적 여유가 없을수 있다. 

BACH 의 어 린 이 부모대 리 기 업 체 때’ on ; CPE) 는 부모들의 요구를 충족 

시 킬수 있는 그 무엇 이 나 다하는 자원자들로 조직된 기 업체 이다. 부모들이 함께 있지 못 
하게 되는 어린이들이나 부모들이 재정적곤난을 겪고 있는 어린이들은 이 기업체의 특별 
한 관심 사로 된 다. 부모들의 요구는 CPE 의 3 개 의 분과위 원회 에 의해 충족되 게 된 다. 즉 
매 어 린이를 매 일 적 어도 30min 동안 누군가가 면회하도록 하는 임무를 수행하는 꼬마친 
구분과(쨔생 Friends- WF), 부모들이 자기 아이 들을 면회 할수 있도록 무임 수송 및 숙박을 
보장하여 주는 가족면회 보장분파 (Jo/m’ng Children with their Families，， JCF), 부모들의 수입 
이 상으로 어 린 이들에 게 놀이감, 학습장，기 타 선물들을 보장하여 주는 임 무를 수행하는 
아동위문분과 (Jwvem’/e Comforts、 JC) 가 있다(이 숙어들에 대한 정보는 다음의 《알고 싶은 
문제》에서 보시오.). 일부 경우에 이 분과위원회들은 서로 협동한다. 실례로 부모들은 
JCF 의 도움으로 병원에 와서 JC 로부터 자기 아이들에게 줄 선물들을 받게 된다. 이 분과 
위원회들은 모두 최대의 비밀성을 준수하고 있다. 즉 환자나 부모들은 이러한 자선사업 
을 누가 하였는가를 전혀 알수가 없다. 어 린이부모대 리기 업체 는 병 원의 콤퓨터체 계를 리 
용하여 자기들의 원조를 필요로 하는 어린이들을 계속 추적하고 싶어 하지만 병원측은 
의 학적비밀준수를 리유로 이것을 허 용하지 않을것 이 다. 이 로부터 CPE 는 자기 자신의 쏘 
프트웨어 제 품을 만들기 로 결 심하였 다. 

이름들은 모두 다음과 갈은 형식을 취한다(아래에서 선택마당들을 중괄호안에 넣었다.). 

세례명 (15 개 문자까지) 

[성의 첫 문자 (1 개 문자)] 

이 름 (15 개 문자까지) 

[이름뒤붙이 (5 개 문자까지)] 
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알: 2 싶 e ©제 

부록 1 의 략어 와 관련하여 유모아적 으로 말하면 요한 쎄 바스치얀 바흐 (Johann S jastian 
Bach; BACH) (역 자주 : 독일의 작곡가 (1685-1750)) 는 자기의 첫 안해 인 사촌 마리 이 Maria) 
한데서 7 명의 자식을 보았고 두번째 안해 인 안나 마그달레 나 (Anna Magdalena) 에 게 • I 13 명 
의 자식을 더 보았다. 이 아이들은 모두 상당한 음악적재능을 보여 주었다. 그중 네 아들들 
은 응당 유명한 작곡가로 된것으로 생각된다. 즉 칼 필 리프 엠마뉴엘 (Carl phillipp E Lanuel; 
CPE), 월헬름 프리 에 데 만 (Wilhelm Friedemann ; ER), 요한 크리 스토프 프레 드리 J Joham 
Chistoph Friedrich; JCF) 와 요한 크리 스치 얀 (Johann Christian; JC) 들이 다. 


주소들은 모두 다음과 갈은 형식을 취한다. 

주소의 첫행 (25 개 문자까지 ) 

[주소의 두번째 행 (25 개 문자까지)] 

도시 (14 개 문자까지) 

나라，주 혹은 지 역 (14 개 문자까지) 

[우편대호 (10 개까지의 문자, 수자，련결부호, 공백)] 

고향 (20 개 문자까지) 

전화번호들은 모두 다음의 형식을 취한다. 

[+ 기호와 뒤이어 나라코드 (3 개의 수자까지)와 련결기호 (-)] 

지 역코드 (3 개 의 수자까지 ) 

련결 기호 (-) 

지 역코드 (4 개 의 수자까지 ) 

련결 기호 (-) 

수자 (4 개의 수자까지) 

[ Ext 에 뒤이어 6개수자까지의 확장수자] 

날자들은 모두 다음의 형식을 취한다 : 

YYYY / MM/DD 

시간은 모두 다음의 형식을 취한다 : 

24 h 표시 법 에 의한 HH:MM 

모든 재정자료들은 다음과 같은 형식을 가진다. 
999,999,999,99딸라까지 

매 환자에 대 하여 다음의 정 보를 기 억한다. 

환자이름 

환자번호 (3 개의 수자, 련결부호，2개의 수자, 련결부호，4개의 수자) 
환자부모 혹은 보호자 1 : 

이름 
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환자와의 관계(어머니, 아버지，이붓어머니, 이붓아버지，기타) 

집주소 
[지 역 주소] 

집전화번호 
[지역전화번히 
[환자부모 혹은 보호자 2 : 

(우와 같다.)] 

환자위치 : 

두자리수자의 층번호，련결부호，세 자리수자의 방번호 

담당의 사 : 

이 름 

병 원경 보기 수자(네 자리 수자) 

담당간호원 

(우와 갈다.) 

입원 날자 
퇴원 날자 

부모 혹은 보호자가 브로드랜즈지 역 아동병 원의 926 km 반경 이내 에서 살고 있는가 ( y / n )? 
부모 혹은 보호자가 확실 히 JCF 의 방조를 요구하는가 ( y / n )? 

부모 혹은 보호자가 확실 히 WF 의 방조를 요구하는가 ( y / n )? 

부모 혹은 보호자가 확실 히 JC 의 방조를 요구하는가 ( y / n )? 

가족면회 보장분과경 력 (후에 보시 오.) 

꼬마친구분과경력(후에 보시오.) 

아동면회분과경력(후에 보시오.) 

제 품 이 개 발되 고 있 는 기 간에 는 퇴 원 환자기 록들을 장기 기 억 에 옮길 필 요가 없 다. 

WF 에 그들의 봉사가 필요한가를 통보하는것은 담당간호원의 임무이다. 어떤 환자가 
보호자와 함께 있지 않다는것(또는 부모가 집으로 돌아 갔다는것)을 관찰한 간호원은 그 
환자의 기록을 갱신한다. 요청을 받을 때 WF 사무소에 WF 방조를 요구하는 환자의 이름， 
번호, 방번호에 대한 목록이 제공되여야 한다. 

WF 는 자원면회자명단을 보관하고 있다. 매 자원자들에 대하여 다음과 같은 정보를 
기 억 하여 야 한다 : 

방문자이름 

방문자번호(환자번호와 같은 형식) 

집주소 
집전화번호 
[사무실 전화번히 
[확스번히 


530 



[경보기 번히 

주간 매 일 아침 , 점 심마다 자원자가 면회하려 는 환자의 최 대 수 (1 〜4:0은 
( 그 시 각에 리 용할수 없 다는것》을 의 미 한다.) 

면회 자가 환자를 면회한 다음에 다음의 정 보가 입 력 되 여 야 한다. 

면회자번호 
환자번호 
면회 날자 
면회시작시간 
면회 끝시간 

면회 자는 이 환자를 또 면회하려 고 하는가 ( y / n )? 

설 명 문 (100 개 문자이내 의 본문) 

매 일 오후 WF 사무소는 다음날 병문안 오리 라고 예상되는 자원자들의 명 단, 그들이 
면회하려 는 최 대환자수, 자원자들의 전화번호와 관련된 정 보를 요구한다. 이 제 품은 매 
환자마다 한명의 자원자를 할당한다. WF 프로그람의 대중성 으로 인하여 어떤 주어 진 날 
에 면회 자가 너무 적 어 질 문제 는 없다. 반대 로 자원자들을 유지 하기 위하여 제 품은 시 
간표가 작성된 매 자원자들에게 적어도 한명의 환자가 할당되도록 하여야 한다. 그러나 
일 정작성알고리 듬은 이 미 어 떤 환자를 면회 하고 그 환자를 또 면회 하기 를 바라는 면회 자 
에게 우선권을 주어 야 한다. 이 밖에 계 획된 어떤 면회 자가 오지 않는 경우에 대 처하여 
두명의 면회자를《대리》당번으로 할당하여야 한다. 

면회 자들이 할당되 였 을 때 제 품은 환자들의 이 름，번호，방번호를 렬거하여 주는 매 
면회 자를 위한 인쇄 지 를 인쇄한다. 매 면회 자들의 인쇄 지에 대 한 정 보를 병 합하고 있는 
주목록표를 인쇄 한다. 

어떤 보호자가 어 떤 어 린 이 를 면회 하기 위 한 재 정 적 방조를 필 요로 한다는것을 담당 
간호원이 알아 차린 경우에 그것을 가족면회보장분과에 통보하는것도 담당간호원의 임무 
이다. 가족들이 이와 같은 봉사를 요구한다고 간주될 때 련관된 어린이의 이름이 그 목 
록의 아래에 추가된다. 그러면 받을수 있는 자금이 그 목록의 상단에 있는 어린이의 가 
족에 할당된다. 그다음 그 어린이는 목록의 하단으로 이동하게 된다(예산의 제약으로 인 
하여 JCF 는 한명의 면회자에게만 지불할것 이다. 또한 부모들이 브로드렌즈의 926 km 반경 
밖에서 살고 있는 어린이에 대해서는 JCF 가 지불을 하지 않는다.). 

하나의 기록에 매 가족면회 에 대 한 내용을 보관한다 : 

환자번호 
환자이름 

부모 또는 보호자의 이름 
환자와의 관계(앞을 참고하시오.) 

면회시작날자 
면회 끝날자 
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면회를 위한 예산량 
실지 면회비용 

설 명 문 (100 개 문자이내 의 본문) 

마지막으로 담당간호원이 입력한 정보에 기초하여 가족위문분과사무소를 위한 
요청에 대한 목록이 인쇄된다. 이 절차는 JCF 에서 리용한 목록과 류사하다. 즉 어린이가 
이러한 봉사를 요구한다고 간주될 때 련관된 어린이가 목록의 하단에 추가된다. 그리고 
받을수 있는 자금이 목록의 상단에 있는 어린이에게 할당된다. 그다음 그 어린이는 
목록의 하단으로 이동하게 된다. 그러나 어디에 살고 있는가에 관계없이 봉사를 
요구하는 모든 어린이들이 JC 의 적격자로 된다. 어떤 어린이들을 면회하는 어떤 
보호자가 그 어린이에게 줄 선물을 가지고 있도록 JC 와 JCF 를 통합하는것이 필요하다. 
그러므로 어떤 JCF 면회가 JC 의 적격자로 되는 어떤 어린이에게 대하여 계획될 때 그 
어린이는 JC 목록의 상단으로 이동하여야 한다. JCF 로부터 JC 에로 이행에 관한 보고서는 
다음의 내용을 포함한다. 

환자번호 
환자이름 
면회시작날자 
설 명 문 (100 개 문자이내) 

하나의 기록이 매 선물에 대한 내용을 보관한다. 

환자번호 
환자이름 

선물을 받은 날자 
선물내 용 (50 개 문자이내) 

선물비 용 

설 명 문 (100 개 문자이내) 

최종제품이 적당할 때 병원측은 어떤 환자가 입원할 때마다 다음과 같은 정보 즉 환 
자의 이름，번호，부모 또는 보호자, 주소, 담당의사，담당간호원자료를 제공할것이다. 제 
품이 개발되는 기간 이 정보는 어떤 환자가 CPE 봉사를 요구할 때마다 BACH 직원에 의 
해 수동적으로 입력될것이다. 
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부록 2. 쏘프트웨어공학자원 


쏘프트웨어공학주제에 대한 정보를 더 엄는데는 두가지 방법이 있다 . 즉 잡지들과 
대 회 토론회 회 보를 리 용하는 방법 이 있고 다음에 는 인터 네 트와 World Wide Web 를 리 용 
하는 방법 이 있다. 

IEEE Transactions on Software Engimering 와 같은 쏘프트웨어 공학전용잡지들이 있 다. 
또한 Communications of the 셨 CM 과 같은 보다 일반적 인 잡지들이 있는데 여기에는 쏘 
프트웨어 공학에 대 한 중요한 기 사들이 게재되 여 있다. 지 면상리 유로 하여 아래 에 두 부 
류의 잡지 들만 선택하여 제 시하였 다. 

ACM Computing Reviews 

ACM Computing Surveys 

ACM SIGCHI Bulletin 

ACM SIGPLAN Notices 

ACM SIGSOFT Software Engineering Notes 

ACM Transactions on Computer Systems 

ACM Transactions on Programming Languages and System 

ACM Transactions on Software Engineering and Methodology 

Communications of the ACM 

Computer Journal 

IBM Journal of Research and Development 
IBM System Journal 
IEEE Computer 
IEEE Software 

IEEE Transactions on Software Engineering 
Journal of Software Maintenance: Research and Practice 
Journal of Systems and Software 
Software Engineering Journal 
Software—Practice and Experience 


이밖에 여러 대회회보에는 쏘프트웨어공학에 대한 중요한 론문들을 포함하고 있다. 
또한 그 주제들에 대 하여 아래 에 제시해 주었다. 대부분의 대회들에는 그 략칭 이 나 발기 
기업체의 이름을 괄호안에 주었다. 
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ACM SIGPLAN Annual Conference (SIGLAN) 

ACM SIGSOFT Symposium on the Foundations of Software Engineering(FSE) 

Conference on Human Factors in Computing Systems (CHI) 

Conference on Object-Oriented Programming System, Languages, and Applications(OOPSLA) 
International Computer Software and Applications Conference(COMPSA C) 

International Conference on Software Engineering^CSE) 

International Conference on Software Maintenance(ICSM) 

International Conference on Software Reuse(ICSR) 

International Conference on the Software Process(ICSP) 

International Software Architecture Workshop(ISA W) 

International Symposium on Software Testing and Analysis(ISSTA) 

International Workshop on Software Configuration Management(SCM) 

International Workshop on Software Specification and Design (IWSSD) 

인터네트는 쏘프트웨어공학에 대한 또 하나의 가치 있는 정보원천으로 되고 있다. 
Usenet news group 과 관련하여 다음의 두개 가 시종일관하게 유용한것 으로 되 고 있 다. 

comp.object 

comp.software-eng 

관련된다고 보는 항목들을 때때로 포함하고 있는 기타 다른 newsgroup 에는 다음과 
같은것들이 있다. 

comp.lang.c++. moderated 
comp.lang.java.programmer 
comp.risks 

comp.software.config-mgmt 
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부록 3. 항공읃식전문회사 실례연구 : 

C 신속원형 

항공음식전문회사 실례연구를 위한 C 신속원형은 WWW 의 www.mhhe.com/engcs/co 
mpsci/schach 에서 리용할수 있다. 


부특 4. 항공음식전문회사 실례연구 : 
JAVA 신속원형 


항공음식전문회사 실례연구를 위한 Java 신속원형은 WWW 의 www.mhhe.com/engcs/c 
ompsci/schach 에서 리용할수 있다. 


부특 5. 항공음식전문회사 실례연구 : 
구조화체계분석 


1단계 : 자료흐름선도를 작성한다. 

이것은 11. 14에서 서술한다. 

2단계 : 어느 부분을 어떻게 콤퓨터화하겠는가를 결정한다. 

DFD 에 보여 준것 처 럼 완전한 제 품을 건반구동형 식 의 직 결독립형 제품으로 
콤퓨터 화한다. 

3단계 : 자료흐름들의 세 부들을 작성한다. 

특별 식 사류형 (어 린 이 용, 당뇨병환자용, 유태 인 용，회 교도용, 무유당, 저카로 
리，저콜레 스테 롤，저지 방，저 단백，저염，해산물，남새료리) 

승객 항목 

예약식별자 (6 개의 대문자) 

승객 이 름 

세례명 (15 개 문자까지) 

[성의 첫 문자 (1 개 문자)] 
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이름 (15 개 문자까지) 

[ 이 름뒤불 이 (5 개 문자까지 )] 

승객 주소 

주소의 첫행 (25 개 문자까지 허용) 

[주소의 두번째 행 (25 개 문자까지 허용)] 

도시 (14 개 문자까지 허용) 

[나라，주，또는 지 역 (14 개 문자까지 허용)] 

[우편대 호 (10 개 문자까지 허 용되 며 수자, 련결 기 호, 공백 을 리용)] 
고향 (20 개 문자까지 허용) 

날자항목 (9 개 문자) 

일 (2 자리 수자) 

월 (3 개의 대문자) 

년 (4 자리 수자) 

비행수자항목 (3 자리수자, 빈 자리는 오른쪽에서부터 0으로 채워 진다.) 
좌석번호항목 

렬번호 (3 자리수자，빈 자리는 오른쪽에서부터 0으로 채워 진다.) 
좌석 식 별 자(대 문자로) 

일 반예 약항목 

예약식별자 (6 개의 대문자) 

비 행번호(앞의것 을 보시 오) 

비 행날자(앞의것 을 보시 오) 

좌석 번 호(앞의것 을 보시 오) 

승객항목(앞의것 을 보시 오) 

[특별식사류형(앞의것을 보시오)] 

예 약항목 

예약식별자 (6 개의 대문자) 

비 행번호(앞의것 을 보시 오) 

비 행날자(앞의것 을 보시 오) 

좌석 번 호(앞의것 을 보시 오) 

승객항목(앞의것 을 보시 오) 

특별식사류형(앞의것을 보시오) 

승객이 비행기에 올랐는가? (1 개 문자) 

식사가 오른 상태 (1 개 문자) 

평가된 식사의 질(1~5) 

특별 식 사항목(예 약항목과 마찬가지 로, 앞의것 을 보시 오.) 

료리조달자보고항목 

비 행번호(앞의것 을 보시 오.) 

비 행날자(앞의것 을 보시 오.) 

특별 식 사류형 (앞의것 을 보시 오.) 



오른 식사항목 

특별식사세부(앞의것을 보시오.) 

식사가 오른 상태 (1 개 문자) 

퍼센트보고항목 

규정된대로 오른 특별식사비률 (3+2 개의 수자) 

특별식사를 주문한 승객이 비행기에 오른 비률 (3+2 개의 수자) 

특별 식 사를 주문하였 지 만 그 식 사가 오르지 않은 승객 들의 비률 (3+2 개 
의 수자) 

오르지 않은 식사보고항목 

승객항목(앞의것 을 보시 오.) 

비 행날자(앞의것 을 보시 오.) 

특별 식 사류형 (앞의것 을 보시 오.) 

저품질식사보고항목 

승객항목(앞의것 을 보시 오.) 

비 행날자(앞의 것 을 보시 오.) 

특별식사류형(앞의것을 보시오.) 

평가된 식사의 질(1~5) 

저 염 식 사보고항목 

비 행번호(앞의것 을 보시 오.) 

비 행날자(앞의것 을 보시 오.) 

평가된 식사의 질(1~5) 

시 작 및 마감날자 

시 작날자(앞의것 을 보시 오.) 

마감날자(앞의것 을 보시 오.) 

승객식사평가 

예약식별자 (6 개의 대문자) 

평가된 식사의 질(1~5) 

4단계 : 공정 의 론리 를 정 의 한다. 

예 약을 입 력한다. 

승객으로부터 예약세부자료를 엄어 낸다. 

오른 식사보고서를 작성하고 조사한다. 

비행기안내원들은 모든 식사가 다 올랐다는것을 표식한다. 대 응하는 식 
사탑승상태마당이 후에 Y 로 설정된다. 

탑승보고서 를 작성한다. 

어 떤 특정한 비 행번호에 대 한 특별식 사요구들이 인쇄된다. 

특별식사요구를 추출한다， 

만일 예 약에 어 떤 특별 식 사가 포함되 면 그 예 약은 적 당히 표식한다. 


537 



우편엽서를 생성한다. 

어떤 특별식사를 받은 매 승객에 대하여 그 승객의 세부자료가 들어 
있는 우편엽서를 생성한다. 

우편엽서를 조사한다. 

우편엽서가 되돌아 올 때 예약식별자를 확인하고 평가된 식사품질을 
기록한다. 

료리 조달자보고서 를 작성 한다. 

어떤 주어 진 비행날자와 비행기번호에 대하여 요청된 식사를 인쇄한다. 
퍼센트보고서를 작성한다. 

어떤 주어 진 시작날자와 마감날자에 대하여 규정된대로 오른 특별식 
사의 퍼센트, 특별식사를 주문한 승객이 비행기에 탑승한 퍼센트，특별 
식사를 주문하였지만 오르지 않은 비행기에 탑승한 승객들의 퍼센트를 
계산하고 인쇄한다. 

오르지 않은 식사보고서를 작성한다. 

어떤 주어 진 시작날자와 마감날자에 대하여 식사가 한번이상 오르지 
않은 매 승객의 이름과 주소 및 그 사건의 발생날자를 인쇄된다. 

저품질보고서를 작성한다. 

어떤 주어 진 시작날자와 마감날자에 대하여 평가한 식사품질이 4 또 
는 그이하인 승객 들의 이 름과 주소 및 그 사건의 발생날자, 식 사류형 을 
인쇄 한다. 

저염식사보고서를 작성한다. 

어떤 주어 진 시작날자와 마감날자，봉사한 매 저녁식사에 대하여 비행 
기번호와 그 사건의 출현날자, 평 가된 식 사품질 을 인쇄한다. 

5단계 : 자료저 장을 정 의한다. 

RESERVATION DATA (187 바이트) 

예약식별자 (6 개의 대문자) 

비 행번호 (3 자리 수자，빈 자리 는 오른쪽에 서 부터 0으로 채 워 진다.) 

비 행날자 (9 자리 수자:2자리수자로 된 날자，3개 의 대 문자로 된 월，4자리 
수자로 된 년) 

좌석번호 (3 자리수자，빈 자리는 오른쪽에서부터 0으로 채워 진다.) 

예약식별자 (6 개의 대문자) 

세례명 (15 개 문자까지) 

성의 첫 문자 (1 개 문자) 

이름 (15 개 문자까지) 

이름뒤붙이 (5 개 문자까지) 

주소의 첫행 (25 개 문자까지 허용) 

주소의 두번째 행 (25 개 문자까지 허용) 

도시 (14 개 문자까지 허용) 

나라，주，또는 지역 (14 개 문자까지 허용) 
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우편대 호 (10 개 문자까지 허 용되 며 수자，련결 기 호, 공백 을 리용) 

고향 (20 개 문자까지 허용) 

특별식사류형 (15 개 문자까지) 

특별식사표식 (1 개 문자) 

SPECIAL MEALS DATA (192 바이트) 

RESERVATION DATA (앞의 것 을 보시 오.) 

승객이 비행기에 올랐는가? (1 개 문자) 

식사가 오른 상태 (1 개 문자) 

평가된 식사의 질(1~5) 

RESERVATION DATA 에 대 한 즉시 접 근은 예 약식 별 자 (1 차)와 이 름과 좌석 
번호에 의해 실현된 다. 

SPECIAL MEALSS DATA 에 대 한 즉시접 근은 예 약식 별 자 (1 차)와 이 름，좌 
석번호，식 사류형 에 의해 실현된다. 

6단계 : 물리 적 자원들을 정 의한다. 

RESERVATION DATA 
색 인된 순서파일 
1차색인 예약식별자 
2차색인 이름과 좌석번호 
SPECIAL MEALS DATA 
색 인된 순서파일 
1차색인 예약자료 

2차색인 이름과 좌석번호，식사류형 
7단계 : 입 력/출력명세 서 들을 결정한다. 

다음의 공정들을 위한 입 력스크린이 설계될것 이 다. 

예 약을 입 력한다. 

일 반적 인 예 약항목을 입 력한다. 

료리 조달자보고서 를 작성한다. 

비 행번호와 비 행날자를 입 력한다. 

퍼 센트보고서 를 작성한다. 

시 작날자와 마감날자를 입 력한다. 

실 어 지 지 않은 식 사보고서 를 작성한다. 

시 작날자와 마감날자를 입 력한다. 

저 품질 보고서 를 작성한다. 

시 작날자와 마감날자를 입 력한다. 

저염보고서 를 작성한다. 

시 작날자와 마감날자를 입 력한다. 


다음의 보고서 들을 인쇄 할것 이 다 : 
탑승보고서 
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승객이름, 좌석번호, 식사류형 
우편엽서 

승객이름，비행날자，비행번호 
료리조달자보고서 

비행날자，비행번호，식사류형 
퍼센트보고서 

시작날자，마감날자, 명시되여 있는대로 오른 특별식사의 비률, 특별식 
사를 주문한 비행기에 오른 승객들의 비률，특별식사를 주문했으나 그 
식사가 오르지 않은 비행기에 오른 승객들의 비률 
오르지 않은 식사보고서 

시 작날자，마감날자, 승객 이름, 승객주소，발생 날자 
저품질보고서 

시작날자，마감날자，승객이름, 승객주소，식사류형, 평가된 식사의 질, 
발생 날자， 

저 염 식 사보고서 

시작날자, 마감날자, 비행번호, 비행날자, 평가된 식사의 질 
다음의 항목들이 조사될것이다. 

랍승보고서 조사 

예 약식 별 자, 식 사가 오른 상태 
우편엽서조사 

예 약식 별 자，평 가된 식 사의 질 
8단계 : 규격 화를 수행 한다. 

두개의 완성된 예약기록들은 한개의 512바이트의 디스크블로크에 채울수 있 
다. 만일 비행당 128건의 예약이 있고 항공음식전문회사가 봉사하는 64개의 
매 비행장들로부터 하루에 8번의 비행이 있다고 가정하면 128 GB 의 직결레 
코드가 존재하게 된 다. 

매 일 512개의 탑승보고서를 조사해야 할것 이 다. 만일 승객의 5%가 특별식사 
를 요청하며 그중 절반이 자기 들의 우편엽서 를 되돌려 보낸다면 매 일 1,해0 
개 의 우편 엽 서 를 조사해 야 할것 이 다. 

9단계 : 하드웨 어요구사항을 결 정한다. 

매 비행장관문에 2대의 말단를퓨터와 매 탑승수속지점에 한대의 말단기가 
요구된다. 이 말단들은 항공음식전문회사 망과 련결될것이다. 만일 항공음식 
전문회사가 자기가 봉사하는 64개의 매 비행장에 두개의 관문을 가지고 있 
으며 비행 장마다 8개의 추가적 인 탑승수속말단기가 요구된다면 64개의 말단 
기 를 구입해 야 할 필요가 있 다. 

현재 매 비행기에 탑승된 인쇄기들은 탑승보고서를 찍는데 충분할것이다. 본 
사에 있는 인쇄 기 들은 인쇄해 야 할 각종 보고서 들은 물론 매 일 3,000개 의 우 
편엽서를 찍는데 충분할것이다. 

매일 512개의 탑승보고서와 1,500개의 우편엽서를 조사할수 있는 조사기를 
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구입해야 한다. 관리자측은 모든 조사를 본사에서 수행할것인가(이 경우에 
한대의 조사기와 한대의 여벌조사기가 적당하다.) 아니면 조사를 여러 싸이 
트에서 수행 하겠는가를 결정 하여 야 한다. 


부특 6. 항공음식전문회사 실례연구 : 

쏘프트웨어프로젝트관리계획 

여기서 제시하는 해결방안은 3명 즉 회사 사장 레스 ( Les ) 와 두명의 쏘프트웨어공학자 
들로 구성된 작은 쏘프트웨 어개 발기 업체가 항공음식전문회사제 품을 개 발할 때의 쏘프트 
웨 어 프로젝 트관리 계 획 (Software Project Management Plan ; SPMP ) 이 다. 

1 . 서 론 

1.1 프로젝트개팔 이 프로젝 트의 목적 은 특별식 사를 요청하는 승객 들에 게 그것 을 
계 속 공급하겠는가를 결정할 때 에 항공음식 전문회 사를 지 원하는 쏘프트웨어 제품을 개 발 
하는것이다. 이 제품은 의뢰자가 어떤 예약을 입력하고 어떤 승객의 탑승수속을 하며 특 
별식사계획 을 관리 하기 위해 필요한 정 보를 발생할수 있게 한다. 제 품은 매 비 행 에서의 
특별식 사요구, 식 사품질，오르지 않은 식 사와 관련한 보고서 를 생 성할것 이 다. 

시간, 예산, 개 인적요구사항들은 다음과 같다. 

요구사항확정단계 (1 주일, 두명의 개발림성원，1,750딸라) 

객체지향분석단계 (1 주일，두명의 개발림성 원，1,750딸라> 

계 획단계 (1 주일, 두명 의 개발림 성 원，1,750딸라) 

설 계 단계 (2 주일 , 두명 의 개 발림 성 원，3,500딸라) 

실현 단계 (3 주일, 3명 의 개발림 성 원，7,875딸라) 

통합단계 (2 주일, 3명 의 개발림 성 원，5,250딸라) 

실현단계와 통합단계는 제15장에서 서술한바와 같이 결합된다. 

총 개 발기 일 은 …주이 며 총 내 부비 용은 21,875딸라이다. 

1.2. 프로젝트배포물 완성된 원천코드는 사용자지도서와 조작지도서와 함께 프로젝 
트에 착수한후 m 주후에 배포될것이다. 의뢰자는 제품이 배포될 때까지 권고된 하드웨어 
와 체계쏘프트웨어를 구입할 책임을 지게 될것이다. 

1.3. SPMP 의 진화 SPMP 에서의 모든 변경은 그것을 실현하기전에 사장의 동의를 
받아야 한다. 모든 변경들은 SPMP 가 정정되 고 갱 신될수 있도록 문서 로 작성하여 야 한다. 

1.4. 참고자료 회사의 하나의 코드작성표준, 문서작성기준，시험기준 

1.5. 정의와 략어 SPMP — Software Project Management Plan (쏘프트웨 어 프로젝 트관리 
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계획) 


2. 프로젝트의 구성 

2.1. 공정모형 리 용하는 쏘프트웨 어생명주기모형은 신속원형 을 가진 폭포모형 이 다. 
명세서 는 다나 ( Dana ) 와 린드씨 ( Lindsey ) 가 작성 하였으며 레 스 ( Les ) 와 의 뢰 자의 면담에서 
의뢰 자에 의해서 검증되 였다. 사장은 전반적 인 설계를 검 토한다. 코드작성은 다나와 린드 
씨 가 진행하였 다. 그들은 상대 방의 코드를 시 험하며 사장은 통합시 험 을 지 휘한다. 그다음 
확장시 험 은 3명모두에 의해서 진행 된다. 이 모든 활동에 필요한 시 간은 서 론에 제 시 된다. 

2.2. 기업체의 구성 개 발림은 레스(사장)，다나와 린드씨(쏘프트웨 어기사)로 구성된다. 

2.3. 기업체의 경계와 호상결합 이 프로젝트상에서의 모든 작업은 레스, 다나，린드씨 
에 의해서 수행된다. 레스는 매주 의뢰자와 만나 프로젝트진척정형을 보고하고 가능한 
변화와 변경들에 대하여 토론한다. 일정표 또는 예산에 영향을 줄 모든 중요한 변경들에 
대해서는 사장의 허가를 받고 문서화되여야 한다. 외부로부터 그 어떤 쏘프트웨어품질보 
증성원도 인입시키지 않는다. 매 사람이 다른 사람의 작업제품을 시험하여 개발자가 아 
닌 다른 사람이 그 시험을 하여 얻게 되는 리득을 획득하게 한다. 

2.4. 프로젝트책임 매 성원들은 자기가 코드작성한 모둘의 질에 대하여 책임진다. 사 
장은 클라스정의표와 보고서모둘들을 다루며 다나는 비행정보를 처리하는 모둘들을 작성 
하며 린드씨는 승객정보를 처리하는 모둘들을 코드작성한다. 사장은 제품의 모둘통합과 
전반적 품질 이 의 뢰 자의 요구를 충족시 키 는가를 감독한다. 

3. 관 리 공 정 

3.1. 관리목적과 우선권 최종목적은 오유 없는 제품을 제때에 제한된 예산안에서 배 
포하는것이다. 만일 이 목적을 달성할수 없다면 매 비행에 대한 특별식사를 주문하는데 
요구되는 루턴들을 완성하는데 보다 높은 우선권이 부여되며 기타 보고서들을 보다 낮은 
우선권을 가지게 된다. 

3명 의 개발림성 원들은 자기 들이 맡은 모둘상에 서 개 별적 으로 작업한다. 레 스의 역 
할은 다른 두 사람의 매 일 작업진척정형을 료해 하고 통합을 료해하여 제 품의 전반적질 
을 책 임 지 며 의 뢰 자와의 호상련계 를 맺 는것 이 다. 개발림성 원들은 매 일 작업마감에 만 
나서 문제점들과 진척정형에 대하여 토론한다. 의뢰자와의 공식면담은 매주 말에 진행 
되며 이때 프로젝트진척정형을 보고하고 어떤 변경이 만들어 질 필요가 있겠는가를 결 
정 한다. 사장은 일정과 예산요구조건들이 만족된다는것을 담보하게 된다. 위험요소관리 
역시 사장의 책임이다. 

오유를 최소로 하고 사용자와의 친밀성을 최대로 보장하는것이 사장의 최우선책임이 
다. 사장은 또한 모든 문서들에 대하여 책임지며 그것이 갱신된다는것을 담보하여야 한다. 

3.2. 가정, 종속, 계약 인수판정기준이 명세서에 렬거된다. 이밖에 
최종기한이 만족되여 야 한다. 

예산제약이 만족되여야 한다. 


542 



제품은 신뢰성 이 있어 야 한다. 

추가적인 모둘들이 후에 추가될수 있도륵 구성은 열린 방식으로 되여야 한다. 

제품은 의뢰자의 하드웨 어조건을 만족시켜 야 한다. 

제품은 사용자에게 친절하게 만들어 져 야 한다. 

3.3. 위험요소관리 위험 인자들과 그것을 추적하기 위한 기구는 다음과 갈다. 

會새 제품과 비교할수 있는 현존 쏘프트웨 어는 없다. 따라서 현존 제품과 병렬로 
실행될수 없다. 그러므로 제품은 확장시험을 받아야 한다. 

讀의뢰 자는 를퓨터에 대한 경험 이 없다고 가정된다. 그러므로 명세 작성단계와 
의뢰자와의 정보교환에 특별한 주의를 돌려야 한다. 제품은 될수록 사용자에 
게 친절하도록 개발되여야 한다. 

.기 본설계 오유가 언제 나 존재할수 있 다. 그러 므로 확장시 험 은 설계 단계 에서 
수정된다. 또한 매 개발림성원들이 자기가 작성한 코드를 우선 시험하고 다 
른 성원의 코드를 시험한다. 사장은 통합시험을 책임진다. 

_제품은 규정된 기억요구들과 응답시간들을 충족시켜야 한다. 이것은 제품의 
규모가 작기때 문에 기본문제로 될것 같지는 않지만 사장은 개 발 전 기간에 
걸쳐 이에 대하여 료해해 야 한다. 

_드물게 하드웨어가 고장날 경우가 있다. 이 경우에는 다른 기계가 임대될것 
이다. 만일 콤파일러에 장애가 있다면 그것은 교체될것이다. 이것들은 하드 
웨어와 를파일러공급자들에게서 받게 되는 담보서에 포함된다. 

3.4. 검사 및 조종기구 사장은 모든 검토와 재정검사를 책임진다. 이것4 사장이 매 
일 개 발된 성 원들과 면담하는것을 통해 실현된다. 매 면담에서 다나와 린드는 그날 작업 
진척정형과 문제점들을 보고한다. 사장은 작업이 예상대로 진척되고 있는가 그리고 명세 
서 와 SPMP 를 준수하고 있는가를 결 정한다. 개발림 성 원들이 직 면 하고 있는 중요한 문제 
점들은 즉시 사장에게 보고된다. 

3.5. 직원재용계획 레스는 10 주 전 기간 필요하며 첫 5 주간은 경영자적권한만을 행사 
하며 나머 지 5 주간은 경 영 자와 프로그람작성 자의 역 할을 수행한다. 다나와 린드는 10 주 
전 기간 필요하다. 


4. 기술적공정 

4.1. 방법, 도구，기법 신속원형을 가진 폭포모형이 리용된다. 신속원형은 C 로 작 
성된다. 명세서 는 객체지향분석수법 을 리용하여 작성된다. 객체지향설계 가 리 용된다. 
원천코드는 C ++ 또는 Java 로 작성되며 개인콤퓨터상의 Linux 환경하에서 실행된다. 문 
서작성 과 코드작성 은 회 사의 표준에 따라 수행 된 다. 

4.2. 쏘프트웨어문서 쏘프트웨어 문서 는 회 사의 표준에 준하여 작성 된 다. 문서 에 대 한 
검토는 공정모형의 매 단계가 완성될 때 레스의 지도하에 수행된다. 이것은 어떤 특정한 
단계에서의 모든 문서작성이 다음단계가 시작될 때까지 완성되게 된다는것을 담보하고 
있 다. 

4.3. 프로젝트지원기능 품질보증은 2.1 에서 서술한것과 마찬가지 로 수행된다. 
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5. 작업패키지, 일정표，예산 


5.1. 작업패키지 여기 에 포함되는 항목들은 비행, 승객, 식사이다. 특별식사에 대한 
정보들을 저장하고 식사요구, 식사품질，식사가 올랐는가에 관한 보고서를 생성하기 위한 
루린들이 요구된다. 이 매개 항목들에 대한 방법들은 독립적으로 만들어 진다. 개발림성 
원들은 항시적으로 정보교환상태에 있으며 이것은 클라스의 무모순성을 담보하여야 한다. 

5.2. 종속성 종속성은 공정모형에 명시된것과 마찬가지 이다. 특히 선행한 단계의 작업 
제품이 사장의 허가를 받기전까지는 그 어떤 단계도 시작될수 있다. 

5.3. 자원요구 표준리눅스도구와 함께 리눅스환경하에서 동작하는 3대의 를퓨터가 요 
구된 다. 

5.4. 예산 및 자금분배 매 단계 에 대 한 예산안은 다음과 같다. 


요구사항확정 단계 

1,750딸라 

객 체 지 향분석 단계 

1,750딸라 

계 획 작성 단계 

1，750딸라 

객 체 지 향설 계 단계 

3,500딸라 

실 현 단계 

7,875 딸라 

통합단계 

5,250딸라 

총계 

21,875 딸라 


5.5. 일정표 

1주. 의뢰자와 만나서 요구사항들을 결정한다. 

신속원형 들을 생 성 하고 의 뢰 자와 사용자들이 신속원형 을 허 가한다. 

1주. 명세서를 작성하고 명세서를 검토한다. 의뢰자가 그 문서를 허가한다. 

3주. SPMP 를 생성 하고 SPMP 를 검 토한다. 

4주와 5주. 객체지향설계문서 를 작성 하고 객체지향설계 를 검 토한다. 

상세 설계문서 를 작성 하고 상세 설계 를 검 토한다. 

6주~8주. 매 모둘을 실현하고 검토하며 모둘들을 시험하고 문서화한다. 

9주와 10주. 모둘들을 통합하고 개 별적모둘들을 검 토하며 제 품시 험 을 진행 하고 
문서를 검열한다. 

추가적인 요구들 

'全안. 제 품을 리용하기 위한 통과단어 (암호)가 요구된 다. 

숙련. 숙련은 제 품을 배 포할 때 사장이 수행하게 된 다. 이 제 품은 리용하기 간단 
하기때 문에 숙련 하는데 3일 이 면 충분하다. 사장은 제 품의 사용 첫 해 동안에 는 무 
료로 발생한 문제 점 들에 답변을 줄것 이 다. 

제, .XI 정비. 교정유지정비는 12 개월이내에는 무료로 개발림이 진행하게 된다. 
능력확장과 관련한 개 별적 계 약들이 작성된다. 
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부록 7. 항공읃식전문회사 실례연구 : 
객체지향분석 


항공음식전문회사제품을 위한 완전한 객체지향분석은 12.8 에 제시하였다. 


부특 8. 항공음식전문회사 실례연구 : 
C ++ 실현을 위한 설계 


항공음식전문회사제품의 구성(객체지향)설계는 13. 13에 제시되였다. 항공음식전문 
회 사제 품의 C ++ 판본완전상세설계 에 리 용된 44개 의 방법 들이 클라스이 름과 그 클라스 
이름내 에서의 방법이름에 관하여 자모순서 로 제시된다. 그다음에 3가지 기능들이 자 
모순서 로 제 시된다. 매 클라스의 이 름은 구성 방식설계 에서 와 같지 만 문자 C 로 시 작 
된 다. 


모둘이름 

CCatererReport: : getQualifications 

모둘형 

방법 

귀환값형 

void 

입력 변수 

없음 

출력변수 

없음 

오유동보문 

만일 날자가 부정확하게 입 력되 였으면 

호출된 파일 

없음 

변경된 파일 

없음 

호출된 모둘 

CDate::validDate 

해설 

음식 조달자로부터 비 행 날자와 비 행 번호를 검 색 
하고 검증한다. 
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모둘이름 


CCatererReport::qualifiesForRecord 

방법 





모둘형 


귀환값형 

BOOLEAN 

입력 변수 

CFlightRecord 

출력 변수 

없음 

오유동보문 

없음 

호출된 파일 

없음 

변경된 파일 

없음 

호출된 모둘 

없음 

해설 

만일 사용자가 명기한대로 비행날그 


가되여 있으면 이 보고서를 위한 


한다. 















모 f 이듬 


CFlightRecord: xheckFlightNum 
방법 


귀환값형 


입 력 변수 
출력 변수 


오유동보문 
호출된 파일 


없음 

없음 


없음 

없음 


변경된 파일 


없음 


호출된 모둘 


없음 


해설 


비 행번호가 유효하면 TRUE 를 국 
3개 까지 의 수자로 구성되 여 있 으 
행번 호는 오른쪽에 령 을 맞추어 









모둘이름 


CFlightRecord: :getReservation 

모둘형 I 


귀환값형 

void 

입력 변수 

없음 

출력 변수 

없음 

오유통보문 

예 약 ID 가 이 미 존재 하는 경 우; 

예 약 ID 가 6 개 문자로 구성되 여 있지 않는 경우; 

비 행번호가 3 개 수자로 되 여 있지 않는 경 우; 

날자가 부정확하게 입력되여 있는 경우; 

좌석이 이미 예 약되여 있는 경우; 

좌석번호가 3 개 이내의 수자와 그에 뒤 이은 하나 
의 대문자로 되여 있지 않는 경우; 

호출된 파일 

없음 

변경된 파일 

없음 

호출된 모둘 

CDate::validDate 

CFlightRecord: : alreadyExists, 

checkFlightNum, checkReservationID, 
checkSeatNum, insert, seatReserved 
CPassenger: : getDescription, insert 

해설 

모든 승객정보를 검색한다. 


모둘이름 

CFlightRecord: : insert 

모둘형 

방법 

귀환값형 

void 

■1^ 

없다 

출력 변수 

없다 

오유동보문 

없다 

호출된 파일 

fltRec . dat , tempF.dat 

변경된 파일 

fltRec.dat, tempF.dat 


CFlightRecord: : read, write 

■■法 





BOOLEAN 


입력변수 ifstream 

출력변수 없 다. 

오유통보문 없다. 

호출된 파일 입 력변수에 지 적된 파일 

변경된 파일 없다. 

호출된 모둘 없다. 

해설 비행기록대상을 fileName 으로부터 읽 

_객체 가 유효하게 읽어 지면 TRUE 를 


모둘이름 

CFlightRecord : : scanPostcard 

모둘형 

방법 

귀환값형 

void 

입력 변수 

없다. 

출력 변수 

없다. 


만일 예약 ID 가 6개 문자로 되여 있지 않는 경우; 

그 正)에 대한 예약이 없는 경우; 

호출된 파일 

없다. 




변경된 파일 
호출된 모둘 


없다. 

CFlightRecord : : alreadyExists , 






모 f 이둠 


CFlightRecord: iscanSpecialMeals 
방법 


귀 환값형 void 

입력변수 없다. 

출력변수 없 다. 

오유통보문 비 행번호가 3개 수자로 되 여 있지 않는 경 우; 

_ 날자가 부정확하게 입력되여 있는 경우 

호출된 파일 fltRec . dat ， tempF.dat 

변경된 파일 fltRec.dat, tempF.dat 

호출된 모둘 CDate::validDate 

_ CFlightRecord: :checkFlightNum, insert, read, wr 

해 설 특정 한 비 행 에 대 한 모든 예 약에 대 하여 (예 1 

호+예 약날자) 식사가 올랐는가를 사용자에_ 
_ 문하고 그다음에 파일을 갱 신한다. _ 

모둘이름 CFlightRecord: : seatReserved 

모둘형 방법 

귀 환값형 BOOLEAN 

입 력변수 없 다. 

출력변수 없 다. 

오유통보문 없다. 

호출된 파일 fltRec.dat 

변경된 파일 없다. 

호출된 모둘 CFlightRecord: : read 

해설 좌석번호가 이미 다른 승객에게 예 약되여 있. 

TRUE 를 귀환한다. 
















오유동보 ' IT 
호출된 파일 


fltRec.dat 


변경된 파일 없다. 

호출된 모둘 CFlightRecord: : read 

CN otLoadedReport :: mark 王 


해설 


CPassenger: : getPassenger 
기초클라스 print 방법을 호떨 
일을 초기화한다._ 


모둘이름 
모둘형 
귀환값형 
입 력 변수 
출력 변수 
오유통보문 


CNotLoadedReport: : prints 
방법 


void 

CflightRecord 

없다. 

없다. 

fltRec.dat 





BOOLEAN 


입 력 변수 
출력 변수 
오유동보문 
호출된 파일 
변경된 파일 
호출된 모둘 


CflightRecord 
없다. 

없다. 

一균瓦 

없다. 

CNotLoadedReport::alreadyEncountered, 


해설 


notLoadedMoreThanOnce 
기 록이 보고서 에 지적된 날자범위公 
날자범 위안에 서 한번 이상 식 사가 
승객이 있을 때 이 보고서의 그 
한다._ 


모둘이름 

COnBoardReport: : getQualifications 

모둘형 

방법 

귀환값형 

void 

입력 변수 

없다. 

출력 변수 

없다. 

오유통보문 

날자가 부정확하게 입력되여 있속 

호출된 파일 

없다. 

변경된 파일 

없다. 

호출된 모둘 

CDate :: validDate 

해설 

탑승보고서에 대하여 비행날자와 비 
색 하고 검증한다. 

































부록 9. 항공읃식전문회사 실례연구 : 
JAVA 실현을 위한 설계 


항공음식전문회 사제 품의 구성 방식(객 체지향)설계 는 13. 13에 제 시된다. 항공음식전 
문회 사제 품의 Java 판본 완전상세설계 에 리 용된 39개 의 방법 들이 클라스이 름과 그 클 
라스이름내 에서의 방법이름에 관하여 자모순서로 제시된다. 그 다음에 3가지 기능들이 
자모순서 로 제 시된다. 매 콜라스의 이 름은 구성 방식설계 에서 와 같지 만 문자 C 로 시 작 
된 다. 
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글라•스이 둠 


방법 이 름 
귀환값형 
입력 변수 
출력 변수 
오유동보문 


CFlightRecord 

checkFlightNur 

void 

없다. 

없다. 

예 약 ID 가 6개 


호출된 파일 
변경된 파일 
호출된 모둘 


그 ID 에 대 한 

"¥ 瓦 

없다. 

CFlightRecord.; 


해설 


_ getReservatic 

특정 한 예 약에 c 
확인 한다. 


클라스이름 

CFlightRecord 

방법 이름 

checkReservati< 

귀환값형 

boolean 

입력 변수 

없다. 

출력 변수 

없다. 

오유동보문 

없다. 






글 gf 스이둠 CFlightRecord 


방법 이 름 

checkSeatNum 

귀환값형 

boolean 

입력 변수 

없다. 

출력 변수 

없다. 

오유통보문 

없다. 

호출된 파일 

없다. 

변경된 파일 

없다. 

호출된 모둘 

없다. 

해설 

좌석번호가 유효하면 (3 개 수자까지 되 
경 우) TRUE 를 귀 환한다; 유효한 좌석번 
자리에 오른쪽부터 령을 채워 준다. 


클라스이름 

CFlightRecord 

방법 이 름 

GetReservation 

귀환값형 

void 

입 력 변수 

없다. 

출력 변수 

없다. 

오유동보문 

예약正)가 이미 존재하는 경우; 

예약正)가 6 개 문자로 되여 있지 않는 경 
비행번호가 3 개까지의 수자로 되여 있 
경 우; 

날자가 부정 확하게 입 력 되 여 있 는 경 우; 
좌석이 이미 예약되여 있는 경우; 
좌석번호가 3 개 이내의 수자와 그에 뒤。 
의 대문자로 되여 있지 않는 경우 

호출된 파일 

없다. 

변경된 파일 

없다. 

호출된 모둘 

CFlightRecord. alreadyExists, 

checkFlightNum, checkReservationID, 





글라•스이 둠 


CFlightRecord 


방법 이 름 


귀환값형 


입 력 변수 


출력 변수 


오유동보문 


없다. 


없다. 


없다. 


호출된 파일 


fltRec . dat , tempF.dat 


변경된 파일 
호출된 모둘 


fltRec.dat, tempF.dat 
없다. 


파일에 있는 특정한 곳에 비 행 기록대상을 삽입 
한다. 



CFlightRecord 


scanPostcard 

귀환값형 

void 

입력 변수 

없다. 

출력 변수 

없다. 


예 약 m 가 6 개 문자로 되 여 있지 않는 경우; 

그 ID 에 대한 예약이 없는 경우; 

호출된 파일 

없다. 

변경된 파일 

없다. 

호출된 모둘 

CFlightRecord. alreadyExists, 
































클라스 이름 CPassenger 

방법 이 름 getPassenger 

귀환값형 boolean 

입 력변수 ID TYPE 

출력변수 없 다. 

오유통보문 없다. 

호출된 파일 passenger.dat 

변경된 파일 없다. 

호출된 모둘 없다. 


파일로부터 searchID 와 ■등 
용하여 승객기 록을 적재ᄀ 
적재되 여 있으면 TRUE 를 













오유동보문 


날자가 부정확하게 입력되여 있는 
마감날자가 시작날자보다 더 앞선 

"균瓦 






부록 1 0. 항공음식전문회사 실례연구 : 
검은틍시험실례 


항공음식 전문희 사제 품을 위 한 검 은통시 험 실 례 의 대 표적 인 실 례 는 경 계 분석 과 기 능 
분석을 리용하여 작성되였다. 

경계 값분석 


날자자료 

날자에 대한 등가클라스 : 

1. 적 당한 위 치 에 서 의 /기 호의 탈락 오유 

2. 날자요소에 서 선두령기 호의 탈락 오유 

(실례로 MAR /6/1998 대 MAR /06/1998) 

3. 달이름요소가 타당한 세문자략어가 아닌 경우 오유 

4. 날자요소< 1 오유 

5. 날자요소>현재 달의 일수 

(윤년에 대 한 시험을 여기서 진행한다. ) 오유 

6. 년요소< 0 오유 

7. 년요소> 2999 오유 

8. MMM / DD / YYYY 형식의 타당한 날자 수용가능 

승객 자료 

passengerlD 에 대한 등가클라스: 

1. <1개 문자 오유 

2. >9개 문자 오유 

3. 9개 문자 수용가능 

세례 명 ( firstName )， 이름 ( lastName ) 에 대 한 등가콜라스: 

1. <1개 문자 오유 

2. 1개 문자 수용가능 

3. 1개 문자로부터 15개 문자사이 수용가능 

4. 15개 문자 수용가능 

5. >15개 문자 기록하지 않음 
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성의 첫 글자 ( middlelnit ) 에 대한 등가콜라스: 

1. <1개 문자 

2. 1개 문자 

3. >1개 문자 

뒤불이 ( suffix ) 에 대 한 등가콜라스: 

1. <1개 문자 

2. 1개 문자 

3. 1개 문자와 5개 문자사이 

4. 5개 문자 

5. >5개 문자 

주소 l ( addressl ) 에 대한 등가콜라스: 

1. <1개 문자 

2. 1개 문자 

3. 1개 문자와 25개 문자사이 

4. 25개 문자 

5. >25개 문자 

주소 2( address 2) 에 대한 등가클라스: 

1. <1개 문자 

2. 1개 문자 

3. 1개 문자와 25개 문자사이 

4. 25개 문자 

5. >25개 문자 

도시 ( city ) 에 대한 등가클라스: 

1. <1개 문자 

2. 1개 문자 

3. 1개 문자와 14개 문자사이 

4. 14개 문자 

5. >14개 문자 

나라 ( state ) 에 대 한 등가콜라스: 

1. <1개 문자 

2. 1개 문자 

3. 1개 문자와 14개 문자사이 

4. 14개 문자 

5. >14개 문자 

우편대호 ( postalCode ) 에 대한 등가콜라스: 

1. >1개 문자 

2. 1개 문자 

3. 1개 문자와 10개 문자 

4. 10개 문자 

5. >10개 문자 


수용가능 
수용가능 
기록하지 않음 

수용가능 
수용가능 
수용가능 
수용가능 
기록하지 않음 


오유 

수용가능 
수용가능 
수용가능 
기록하지 않음 


수용가능 
수용가능 
수용가능 
수용가능 
기록하지 않음 


오유 

수용가능 
수용가능 
수용가능 
기록하지 않음 


수용가능 
수용가능 
수용가능 
수용가능 
기록하지 않음 


수용가능 
수용가능 
수용가능 
수용가능 
기록하지 않음 



고향 ( country ) 에 대 한 등가클라스: 

1. >1개 문자 

2. 1개 문자 

3. 1개 문자와 20개 문자 

4. 20개 문자 

5. >20개 문자 


오유 

수용가능 
수용가능 
수용가능 
기록하지 않음 


기능분석 

예 약작성 

1. reservationID 가 이미 존재한다는 예약작성 

2. 어떤 특별비행을 위한 좌석번호가 이미 예약된다는 예약작성 

3. passengerlD 가 자료기지에 이미 존재한다는 예 약작성 

4. passengerlD 가 자료기 지 에 이 미 존재 하지 않는다는 예 약작성 

승객 검사 

5. preservationID 를 자료기지에서 찾을수 없는 승객을 검사 

6. reservationID 를 자료기지에서 찾을수 있는 승객을 검사 

특별식사목록의 조사 

7. 자료기지 에 존재하지 않는 비 행날자와 비행기번호에 대 하여 특별식사 
목록을 조사 

8. 자료기지 에 존재하는 비 행날자와 비 행기번호에 대 하여 특별식사목록 
을 조사 

우편엽서의 조사 

9. reservationID 자료기지에서 찾을수 없는 반환된 우편엽서를 조사 

10. reservationID 를 자료기지에서 찾을수 있는 반환된 우편엽서를 조사 

보고서 현시 

11 . 매 보고서 에 대 하여 출발날자(실례 로 MAR/10/1995) 가 마감날자(실례 
로 MAR/10/1990) 보다 더 늦어 지는 보고서를 현시 

12. 조달자와 탑승보고서 에 대 하여 자료기 지 에 존재하지 않는 비 행날자와 
비 행기번호에 대 한 보고서를 현시 

13. 25h 조달자 목록의 현시 

14. 탑승식사목록의 현시 

15. 주문한 식사가 한번이상 오르지 않은 승객이 없을 때 비적재보고서를 
현시 

16. 주문한 식사가 한번이상 오르지 않은 승객 이 여 러명일 때 비적재보고 
서를 현시(같은 날자 여러명의 예약이 발행할 때에도 우의 작용을 시 
도한다.) 

17. 품질 이 5 급이하라고 생 각되 는 식 사가 오른 경 우의 승객 이 자료기 지안 
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에 없을 때 저품질식사에 대한 보고서를 현시 

18. 품질 이 5급이하라고 생 각되 는 식 사가 오른 경 우의 승객 이 자료기 지안 
에 여 러명일 때 저품질식사에 대한 보고서를 현시 

19. 퍼센트에 대한 보고서를 현시 

20. 자료기지 에 저염식사항목이 없을 때 저염식사에 대 한 보고서를 현시 

21. 자료지안에 저염식사항목이 여 러개 있을 때 저염식사에 대 한 보고서 
를 현시 


부록 1 1 . 항공음식전문회사 실례연구 : 
C ++ 원천 쿄드 


항공음식 전문회 사제 품을 위한 완전한 C ++ 원천코드는 World Wide Web 의 www . mhhe . 
com / engcs / compsci / schach 에 서 리 용할수 있 다. 


부록 1 2. 항공음식전문회사 실례연구 : 
JAVA 원천 쿄드 


항공음식전 문회 사제 품을 위 한 완전 한 Java 원 천 코드는 World Wide Web 의 www . 
mhhe . com / engcs / compsci / schach 에 서 리 용할수 있 다. 
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구조편집기(도分 wc 상 wre editor) 133, 144 
국제규격화기구 (ISO) 253 
기능모듈 modules) 233, 234 
기능분석 analysis) 469 

1 1 능적모형화 (/i/«c 打 ( 써 a/ modeling) 382 
기법 (technique) 321, 383, 469, 501, 543 
기법에 기초한 환경 (technique-based 
environment) 501 


1 1 존체 겨 I (legacy system) 520 
그\준선 (baseline) 142, 290 
개념탐구(아가 父 객가 exploration) 50 
7H ^X\(developer) 48，74, 319 
7H 발환경 {environment) 296, 500 
개정판조종체계 control system) 142 

객체지향분석 ( 애 /… oriented analysis: 00 A) 
14, 53, 324, 382, 384, 545 
객 체 지 향분석 단계 {object-oriented analysis 
phase) 305, 382, 541, 544 
객체지 향 M 계 (object-oriented design) 387, 
421, 422, 436, 444 

계단식세련 0 여 p>v 初 e refinement) 120, 126 
계 약식 쏘프트웨 어 {contract software) 48 
과제 (to 句 90, 116, 290 
관리 독립성 (managerial independence) 152 


능력성숙도모형 (capac 착 y maturity model) 

14, 66, 504 

내리필침차림표 (pw//- 必 menu) 312 
내부쏘프트웨어 O 상 r«a/ software) 48 
내적인 비용 cost) 276 

ᄃ 

다수프로그람작성 {programming-in-the-many) 
132, 134 

다형성 {polymorphic) 219 
^^{assertion) 165, 167, 168 
도구 (too/) 29, 130, 131，144, 242, 291 


618 





도구통합 (too/ integration) 501 
도식 Ocfema) 363 
도형 사용자대면부 (GUI) 312 
동적 모형 화( 각 )써야 w 紀 modeling) 382, 383, 
389, 392 

등가클라스 (e 分义 class) 467 ， 468 ， 
481 ， 589-591 

대 규모프로그 람작성 {programming-in-the- 
large) 132 

대화식원천준위오유수정프로그람 

(interactive source-level-debugger) 135 
대역변수 (g/oia/ variable) 61 ， 194, 221 
대용 체 ( 때/幻 328, 490, 495 

ᄅ 

로바스트성 161, 175, 178 

론리 (fog/c) 186 

론己 I 〒동 (Jogic-driven) 463 

론리모듈 (/og/c module) 492 

론리적자료흐름 (/t 성 7ca/ data flow) 339 

리정표53, 290, 300 

리용 (■ 방 e) 66, 186, 285, 287 

□ 

마 s 라 폴더 (manila folder) 341 
□ [자르식 01 를짓 ) I 습관 (Hungarian Naming 
Conventions) 457 

명령문피복心 " 태 , coverage) 469 
명목상의 노력 effort) 284 
명세서0 /旧 더 /? az 故써 document) 38, 51, 82, 
129, 155, 163, 235, 346, 411 
^H\(specification) 17, 24, 25, 29, 40, 80, 
89, 130, 222, 323, 510 
명세 작성 (분석 ) 단겨 I (Specification (analysis) 
phase) 25, 29, 37 

모듈 (module) 25, 54, 104 ， 141 ， 186, 201 ， 
415, 545-588 


모듈호상접 속도 (module interconnection 
diagram) 65, 192, 199, 490 
무진 실기 법 (Cleanroom technique) 474 
D I 들웨 어 {middleware) 262 
믿음성 (reliability) 161, 175, 178, 233 

ᄇ 

바그， g) 39, 106, 151，158 
반 대 패 턴 {antipattern) 246 
방법 (me 治 o 次 approach) 35, 56, 83, 133, 
171, 200, 383, 476, 545-567 
방법론 (methodo/ogy) 38, 383 
방법에 기초한 ■ 경 (method-based 
environment) 501 
방송대학(여레 University) 349 
방조 (help) 313 

방어프로그람작성 programming) 
493 

병행판본체계 에 versions system) 

142 

보고서 생 성 프로그람 O/w ᄉ generator) 131, 
144 

복잡성 (orapfea • 少 ) 22, 61, 73, 75, 281, 287 
본질 60, 66 

부전지 ( 戶 oW - 비 390 
분고 | 피 복 、 branch coverage) 469 
분석 (a«a/ 少 sis) 25, 36, 37, 40, 53, 86, 96, 
295 

분석긋 1/ 설계 71 {Analyst/Designer) 370 
비가시성 우 ■ 뉴 ■ 삭 V) 61, 64, 75 
비용 대 리득분석 (coW- 뇨여/化 analysis) 90, 
126 

베타판본(스께 version) 57 


人 

사용자대 면 부통합 (… er interface integration) 
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500 

상담 217 

상세설계 ( 쇼 to/ 故 / design) 37, 47, 54, 411, 
412, 416, 430, 504 

상태 0 故紀 ) 352, 354, 392, 396, 429, 536, 
540 

상 EH 도(心次紀 diagram) 382, 392, 405, 407 
상태 도표 (Statechart) 501 

variable) 39, 221, 396, 476 
상태이행도 0 낭公故 transition diagram) 349, 
392 

상위 CASE 도구 (w 夕夕 er CASE tool) 144, 434 
서두설 명 문 (prologue comments) 458 
선 개 발후유지 정 d I {development-then- 
maintenance) 523 

설계단계 O 자 phase) 18, 25, 37, 54, 

126, 305, 411, 541 

^(performance) 32, 162, 175, 178, 246 
성숙준위 (■■ 抄 level) 67-69, 71, 74, 75, 
143, 147 

소규모프로그 람작성 (programming-in-the- 
smalt) 132 

속성 (attribute) 35, 39, 206, 213, 383, 476 
생명주기 C-qyc/e) 24 
생명주기모형 지)^노 model) 79, 80 

수축포장쏘프트웨 어 {shrink-wrapped 
software) 49 

수평구도정의 ( 사 >" 뇬 0 « 切 / schema definition) 
364 

순차도 O 아 / 이 ce diagram) 385, 424, 436 
순응성 (a 씨 / bm/ 印 ) 61, 62, 73, 75 
승강기문제(/하 problem) 351, 362, 384, 

407, 422 

시한페트리망 (">■/ Petrinet) 360 
시험 0 公다細 g) 18, 48, 53, 56, 58, 120, 131, 
151-153, 158, 163, 164, 174, 229, 298 
신속응용개발 (ra/ 古 / application development) 
331 

id 속운 iM(rapid prototype) 50 ， 84 ， 315, 317, 
330, 404, 442, 535 


실례 변 Xinstancc variable) 39 
s 체 -관련 모형 화 (entity-relationship modeling) 
347, 384 

실현단계 ( ，쪄夕 / 切 w 切 W 公打에 phase) 25, 29, 37, 
56, 130, 541，544 
쌘드위치식실현 및 ■ 합 — iwich 
implementation and integration) 494 

天 

자료구동 ( 쇼切 - 必 7v 레 ) 462 

자료기지 관리체계 (DBMS) 345 

자료사전 (—a dictionary) 130, 144 

자료즉시접근도 (DIAD) 344 

자료지 향설계 design) 411, 

421, 444 

자료흐름도(쇼요公 flow diagram) 65, 84, 
339-341, 369-373, 413, 414, 418 
자료흐를분석 (ctoa flow analysis) 412 ， 433, 
444 

자리부족 201, 205 
자리넘침 ( 아방끼난씨 ) 201，205 
자원 289，290 

^IWiworkbench) 65, 130, 131 ， 144, 500 
작용 33, 34, 186 
작용지 향설계 {action-oriented design) 411, 
412, 444 

적 응유지 정 ᄇ I {adaptive maintenance) 27, 

509 

정공학 engineering) 520 
정보은퍼 1( 句/公 ma 打(써 hiding) 34, 182, 200, 
212, 433 

정적방법 ( 었 method) 496, 518 
정확성 {correctness) 163 
§ o sS {correctness proving) 65, 164, 
165, 367 

주관이 없는 프로그람작성 (egofew 
programming) 106 
주문쏘프트웨어 (cwWom software) 497 
즉 }、\ a 근 (i，tediate access) 344 
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7H ^{incremental development) 97 
직접삼입설명문 ( 切 / 切 e comment) 458 
진 s\(evolution) 508，541 
재공학 520 

재구성 {restructuring) 520 
재작업 (renw 次 ) 155 
제품 ( P ， 이/^) 38, 56, 61 ， 84, 128, 214, 
248, 249, 290, 300, 491 
제품시험 0 가긴功샀상 testing) 497, 504, 520 
제품척도 ( 厂 wc/w 次 metrics) 128 

大 

초기설계모형 (요야 design model) 288 
추상자료형 (aferra 次 data type) 191 ， 200, 
210, 221, 224 

추상제작소 상 factory) 243 
추적가능성 (ZraceaW/ 바 ) 53, 55 
출력수 (/im-oi 사 ) 435 

출력의 최고추상점 (A/gAeM abstract point of 
output) 413, 419 

책 임 구동설겨 | {responsibility-driven design) 

36 

체계분석 ( 목 ) 해와 … analysis) 46, 222, 338, 
433, 501, 535 

최 종적 프로그람작성 {extreme programming 
XP) 14, 17, 90, 100, 116, 117 

ᄏ 

쿄드작성도구 tool) 132, 144 
콤퓨터지 원쏘프트웨어공학(어 aided 

software engineering: CASE) 14, 15, 17, 
129, 132, 145 

클 EI ■ 스-책 임-협 동、 class-responsibility- 
collaboration) 390 

클라스도 (c/aw diagram) 382, 427, 438 

클라스모형 (쏘따 model) 382 

클라스모형화 (C/aw modeling) 382, 383, 


399, 402, 407 

클 己 | 크포장쏘프트웨 어 {click wrapped 
software) 49 


타당성 150 

통계적품질조종 O 섰&노 quality control) 68 
통보 (wzewage) 35，518 
통신순차과정 {communicating sequential 
processes: CSP) 367 

통합단계 ( 切紀 gra 故 ” 2 phase) 25, 29, 37 ， 56 ， 
130, 305, 490, 504, 541，544 
통합모형화언어 (t 여가요넜 Modeling Language) 
14, 382, 383 

통합방법론 Methodology) 383 
통합시험 ( 治상 gra " •(써 testing) 56，497 
통합쏘프트웨 어 개 발공정 ((7 떠 /?& Software 
Development Process) 383 
트랜잭션 (transaction) 419 
트랜잭션분석 ( 々 ■yac " •(써 analysis) 412 ， 

433, 444 

BI (framework) 240 ， 241, 246, 264, 291, 
367 

n 

파라다임 38 

폭포모형 (waterfaU model) 17, 24, 81 ， 85, 
86, 98-100 

표처 B I 프로]람 (spreadsheets) 391 
mM(quality) 129, 151 
프로젝트기능 (pwy'ec 》 function), 290 
페기해 ，) 17, 25, 27, 37, 59, 73 

o 

하위 CASE 도구 (/(»■• CASE tool) 434 
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학습끅선 (/earmmg curve) 223 
합리적 인 통합공정 (—a/ unified process) 
383 

M 동도 (collaboration diagram) 385, 425, 

437 

협 동프로그람작성 (programming-in-the-many) 
449 

형식적기법 (/br_!/ technique) 431, 501 
형식적방법 (/& ，베 / method) 501 
흐를도표 65, 173 

흐를도응집도 (//owe 次 a 가 cohesion) 190 
해결전 르 Ksolution strategy) 335 
행편집문제 problem) 169 
흰통시험 testing) 463 

화면생성 프로그람여 

generator) 131, 

144, 278 

환경 ( 례해 0 130, 131, 144, 159, 160, 
296 

활동抄 ) 38, 248, 290, 292, 411 
회귀시험 Ogm 해에 testing) 58, 83, 514 
회귀조종체계 control system: res) 

500 

ᆻ 

쏘프트웨어 Oo/mw 公 ) 38, 63, 120, 129 ， 

144, 254, 264, 285, 291 ， 322, 497 
쏘프트웨어개발 (5^/hvare development) 38, 
48, 254, 289, 412 

쏘프트웨 어 개 발환경 (^/hvare development 
environment) 65 

쏘프트웨어생명주기 ( 지 /hvare life-cycle) 32, 
36 

쏘프트웨 어 품질 보증 Oq/hvare quality 
assurance: SQA) 50, 69, 80, 152 

쏘프 트웨어 프로젝트 관리계획 (software 
project management plan: SPMP) 25, 38, 
52, 292, 373, 541 


O 

아 = 블리어원천행 source line) 

72 

알파판본 ( 세 ? Aa version) 57 
앞단 (斤아 M-em/) 434 
억제호 arc) 359 
여벌복사 ( 뇨샀씨 ?) 345 
역공학 (reverse engineering) 520 
오유 (fault, error) 20, 33, 35, 39, 40, 128, 
152, 158, 178, 238, 334, 479-481, 510, 
542, 589-591 

오유검출률 (/ 느 . detection rate) 158 
오유검출효률(/뇨心 detection efficiency) 158 
오유개수(/노소 number) 158 
오유밀도 (/ 노 /" density) 158 
오유보고서 (/노소 report) 513 
오유시험 률 0 心 > 망 fault rate) 474 
요구人 I ■항확정 {requirement determining) 24, 
46, 504, 510 

요구사항확정 단계 (Requirement phase) 25, 
37, 49, 50, 73, 86, 130, 274, 306, 324, 
541 

용량시험 (vo/wme testing) 498 
우편 구성 방식 모형 {postarchitecture model) 
288 

우연 (accident) 60 

유리통시험 ( 요뇨公⑶ testing) 463, 466, 

473, 474, 483 

유스-케스도 Oe-owe diagram) 382, 385, 
400, 401 

유스-케 스모형 화 (f/M-owe modelling) 382, 
383, 385, 407 

유지정비 結 mmee) 17, 24, 38, 40, 

88, 89, 204, 247, 248, 509, 515, 517 ， 
523 

유지정비 단계 ( 시섰 … 라 phase) 25, 37, 
58, 130, 305, 508, 523 
유■용성 (utility) 161 ， 175, 178 
응답 {response) 313 
응용프로그람합성 모형 {application 
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composition model) 288 
응용프로그람틀거 EI {application framework) 
241 

이식가능여 w 切씨句 248 
인간-콤퓨터대면부 (HCI) 312 

인공지 능 {artificial intelligence) 65 
인수시험 ( 公 cee / 打公 testing) 25, 57, 497, 
499, 504 

^LWJ\M(job queue) 201, 203, 204, 209, 
210 

일 감우선 도 (job-priority) 201 
일관성검사기 (consistency checker) 130, 

131, 144 

입력수 (/&-/«) 435 
입력의 최고추상점 (po/W of highest 
abstraction of input) 413 
입출력 〒동 (input/output-driveri) 462 
외적인 비용 (ex 於 ■!/ cost) 276 
원나정의방법 (Fferaa definition method, 
VDM) 367 

의릐자 (c//m 公 48, 74, 246, 262, 263, 287, 
310, 319, 428, 429, 441 
완전유 'I 정비 (perfective maintenance) 27, 

509 

워 크스테 01 션 (workstation) 296 
원천 준위 오유수정 프로그람야 m/rce-feve/- 
debugger) 135 ， 136，144 
원천 쿄드조종체계여 wrce code control 


system: sees) 142 


4GL(4 generation language) 452, 454 
Ada 15, 172, 215, 250, 264, 322, 367 
Anna 366, 368, 529 
APL 66 
C 4 I 319 

COBOL 15, 66, 216, 252, 253, 421 
COCOMO 18, 284-288, 297-299 
COCOMO II 287, 288, 297, 298 
ERM 347, 384 
FORTRAN 15, 252, 253, 421 
Gist 366 

Java 322, 418, 421, 439, 443, 450, 473. 

KLOC 158, 237 

MEASL 72 

Modular 66 

Oracle 322, 454 

PASCAL 66 

PL/I 66 

PowerBuilder 322 
PSL/PSA 346, 368 
Rose 399, 434 
SDRTS 433 

Smalltalk 66, 312, 320, 332, 421 
SREM 346, 368, 370. 

UNIX 66, 258, 414, 501 
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